Docker snap tracks request

Those look a lot like version numbers instead of tracks. Tracks are generally meant to aggregate a larger collection of versions that represent a sequence of releases with more distinguished characteristics. I’d expect more like a “17” track that holds the current stable in its respective stable channel, and the upcoming one in candidate.

1 Like

@noise
Is there an equivalent in the docker cycle or are these 3 month cycles the longest?
In terms of Docker-CE(community edition), yes 3-month cycles plus one month window update transition are the longest. The above illustration shows that how Docker Inc runs the new release cycle.
Initially, the general idea here is to keep each docker snap release consistent when the quarterly release is published by Docker Inc.
@niemeyer
For now, indeed, one single new track “17” is enough for quarterly release. On the other hand, to simplify the release process, your suggestion looks better. The downside of my proposal is that I have to request a new track everytime a quarterly release is out. That’s a little bit overkilled on both ends.
So let’s use the track “17” to host the release and keep it consistent with the quarterly release from Docker Inc.

Could you please create it for docker-snap?
Thanks.

I don’t believe 17 is a track, then. 17 is just the year, it will become 18 once we enter that year.

Gustavo, for your proposal, then, we wouldn’t need any tracks, then, just the “latest” one, but in that case people will never know when a snap in “candidate” is stable, as there is a small overlap.

17.03 (the March release) will be stable for 4 months, in your example that will be the one we put in stable, and we will put the next monthly releases in candidate.

But, 17.06 will also be a “stable” version, but we cannot move it to “stable” in your single track suggestion, as 17.03 is still “stable” for one more month.

The idea from Docker is that you have 1 month to move to the new stable release, but that you can do so whenever you want throughout that month. If people are testing 17.06 in candidate and decide they are ready to make the switch, the only way for them to do so is to track --candidate (which is not what they want) or to wait 1 month for 17.06 to be published to --stable (which make them lose the control Docker wants to give them).

I think having a track per quarterly release is what it is more similar to what Docker wants to do. We open 17.03 that we keep open for 4 months. On the 3rd month we open 17.06 (and that becomes “latest”) and people willing to make the switch during that month they can do so switching the track. For people who didn’t switch during that month, will do so automatically once the 4 month support period for 17.03 ends, and we close the track.

Feedback?

Thanks!
Ara.

1 Like

We have both candidate and stable channels on every track.

17.03 will actually be stable forever. It may become obsolete and unsupported, but it won’t go back to being unstable. Every three months there will be a new stable version, and as usual on any software project we need to take a stance on when it’s the time to recommend people to update.

That’s not how it works. We never switch people automatically once they are in a track. If we end up with 17.03 in a track and people select it, they’ll stay there forever. If we close it and fallback to 17.06 we’d be offering 17.06 on a 17.03 track which makes no sense.

What are the stability guarantees across versions in terms of data and API?

Yes, I know, what I meant is that as “17” is not really a version, having a 17 track doesn’t make a lot of sense.

Well, that recommendation is made by Docker, not us. My question is whether there is a way to mimic what Docker wants to do using tracks.

Thanks for explaining how tracks really work.
In any case, if we close the track and people have to manually switch to the newer 17.06 track, it will still be the same case as if they were using upstream (where they have to switch to 17.06).

So, again, I think the only way to use tracks for the CE edition of Docker right now, that could mimic what Docker is offering, is to create a track every 3 months for every mini-LTS release. If we don’t do that, then users using the docker-ce snap won’t have the same opportunities as the people using the .debs from Docker.

If this is not possible because it is not OK to create a track every 3 months, then we shouldn’t create tracks at all, as “17” is not really a version.

Thanks!
Ara

Right, 17 is not really a version, and tracks are not really versions either.

The problem is not the act of creating a track every three months. The problem is the association of a track with every version released, every three months or otherwise. That’s not what tracks are for, and sounds both like a bad precedent and an abuse that will have a price, because soon people will be interested in upgrading across tracks automatically and asking for more features which are really about step-wise versioning, as the ideas above already indicated.

I suggest starting with a single track, and using channels appropriately. That will offer stable and candidate channels which can hold the currently recommended and the upcoming stable versions. We don’t need to move the snap in candidate to stable as soon as it’s released by Docker. It’s fine to wait longer until we know more clearly that the version is good, and then we just update it and everybody gets the latest and greatest.

So what’s a track? I think I might be misunderstanding what a track is, then.

If you look at the diagram that Gary attached, those versions are really places were people can stay, and get stable updates, until they are closed.

If you look to the Docker EE, where LTSs are maintained for 1 year instead of 4 months, would you consider those tracks?

Thanks,
Ara.

Tracks have often been dubbed as LTS channels.
Not sure it fits the schema, but a channel named EE or enterprise could work, if not, them being two different snaps would also be a solution (with aliases in play for the docker command) and some smarts on dual install which tracks solve.

Right, I think in this case it makes the most sense to have a “ce” or “ce-quarterly” track. Releases to that track could follow a pattern like:

  • March 2017: release 17.03 -> ce/candidate
  • April 2017: release 17.03 -> ce/stable
  • June 2017: release 17.06 -> ce/candidate
  • July 2017: release 17.06 -> ce/stable
  • Sep 2017: release 17.09 -> ce/candidate
  • Oct 2017: release 17.09 -> ce/stable
    and so forth…

That allows for users to try out the releases 1 month early on candidate but otherwise be upgraded every 3 months on ce/stable to the latest quarterly.

@sergiusens, @noise Thanks for your guys suggestions.
Yes, I understand the point. Quarterly releases are always iterating on that ce track to compliance with track LTS requirement.
But if we do it like that, it really doesn’t make any sense to have a track to host the quarterly releases. Because we could publish the snap on the candidate and stable channel of the latest track straightaway as you suggested, just like we did for 1.13 docker snap release.

We had a session about tracks in the sprint last week and agreed to open up tracks for use with minor versions, assuming the project is following something similar to semantic versioning. In other words, if the project has a minor release 3.2 and may offer patch/micro releases such as 3.2.1 under it, we’ll accept tracks for that purpose and include a respective regular expression to guardrail its versions under said track.

So it’s okay to have tracks for Docker 17.03, 17.06, etc.

I’ve also provided more comprehensive documentation about channel terminology and policy here in the forum.

Thanks for this.
As 17.03 will come to a close towards the end of July(plus 1 month transition period). It’s a bit late to request 17.03 for now. Also we had a meeting with Docker Inc that the RC of 17.06-CE will go into its freeze tomorrow(5/12). So I think it’s a good timing to request 17.06 rather than 17.03.

Can somebody help create 17.06 track for docker snap?
Thanks in advance.

Hello,

I just created the track “17.06” for docker, is ready to be used.

Regards, Natalia.

Thanks, we’re preparing to use it once official release of docker 17.06-ce is published.

BR
Gary

Hello guys
As mentioned the Docker snap release planning in this thread
> We also plan to request a new track 17.03 for the sake of other people who want to stay with it if they don’t want to switch to 17.06-ce for some reasons when “latest” track is automatically upgraded to 17.06 one month later.

It would be really useful for some users who want to upgrade the snap at their own pace.
Could you grant a new track “17.03” for Docker snap?
Thanks

gary-wzl https://forum.snapcraft.io/u/gary-wzl
June 16

Hello guys
As mentioned the Docker snap release planning in this thread
https://forum.snapcraft.io/t/docker-snap-release-planning/1024

We also plan to request a new track 17.03 for the sake of other people who
want to stay with it if they don’t want to switch to 17.06-ce for some
reasons when “latest” track is automatically upgraded to 17.06 one month
later.

It would be really useful for some users who want to upgrade the snap at
their own pace.
Could you grant a new track “17.03” for Docker snap?
Thanks

Track 17.03 created, let us know if you need anything else!

Thanks for your quick response on 17.03 track creation.
We’ll use it for the upcoming patch version of 17.03 docker snap release.

Hi guys
We’re planning to roll out a new version(17.09-ce) of docker snap soon. It will be the 3rd stable quarterly release.
Can someone kindly help create 17.09 track for docker snap?
Thanks in advance.

BR
Gary

Hi Gary,

I have created this track for Docker, based on Simplified track request process for snaps with predictable cadence since as a reviewer I’ve verified that the snap has existing tracks and the new request conforms to the previous ones, so I’m able to waive the waiting period and the extra votes needed (clearly you have my reviewer +1 vote).

However, could I ask you to please, in the future, open a new topic as per Process for reviewing aliases, auto-connections and track requests whenever you need a track?

If they conform to existing tracks (e.g. like for Docker), I can process them more quickly as described in the simplified process.

Cheers,

  • Daniel

Thanks, roadmr.
Next time I request a new track I’ll create a new topic for it.

BR
Gary