Track request for dvc

store-requests
1

In addition to latest, we would like v0, v1, and v2 (ideally also v3 and so on). These will be used to manage major versions introducing breaking API changes.

Note that dvc is a FOSS --classic snap package and seems a good candidate for Simplified track request process for snaps with predictable cadence

1 Like
2

Hi! Backward-incompatible changes are typically a good reason for tracks, though I typically ask if/whether there’s a recommended upgrade path for your users. If there is and you recommend users upgrade and provide a reasonable data migration/conversion procedure, you potentially wouldn’t need so many tracks.

Does dvc have a release schedule that I could check on how frequent releases are, and how long they stay supported for?

I’m concerned about “so on” - I can create v{0,1,2,3} if those releases are current, and maybe a track for any upcoming/dev releases (but best practice is to put dev releases on latest) but I would need more clarity on how far to go, depending on how many releases are currently out and supported.

It will be once we create the first batch of tracks :slight_smile: The first set, however, does need the usual process with a few votes from reviewers over the next few days.

  • Daniel
3

Hi!
v0 and v1 are current. v0 is in the stable channel and v1 is in the beta channel right now.

We’d really need an explicit v0 and v1 track as part of a best-practice upgrade procedure; this is outlined succinctly enough in the linked GitHub issue that perhaps it could be included somewhere in the docs (https://snapcraft.io/docs/channels)?

True to semver.org, we don’t have a release schedule (the aim is to never ever introduce breaking changes by getting everything right the first time so there should ideally never be major version bumps or need for tracks). This ideal of course inevitably will on occasion be unrealistic, and new major versions will be needed.

This track request is more about managing a transition period from v0 to v1:

  • provide warnings about breaking changes
  • provide a way to suppress the warnings and stay on an old track permanently
  • provide a way to suppress the warnings and upgrade instantly

Tracks (rather than risk levels) are essential to this.

However, as added backup - the v0 branch on github has already diverged from v1 so yes, there will certainly be distinct support for both tracks at least for some time.

4

Thanks for the explanation.

I’m +1 on v0 and v1, and other tracks can then be granted as needed (you will qualify for the simplified process which means a turnaround time of about 1 business day). Let me know if that’s ok.

  • Daniel
1 Like
5

Thanks - sounds great!

6

+1 from me too for v0 and v1 tracks for dvc

7

Apologies, I should have actioned this about a week ago. With the two +1 votes, I’ve created v0 and v1 tracks for dvc.

Cheers!

1 Like
8

Hi Guys!

We are getting ready for an upcoming v2 release and would like to request v2 track for our package.

Thank you!

9

Hi there, +1 from me as reviewer and this is done, v2 is available now.

  • Daniel
2 Likes