Could you help create two tracks for docker-snap?
One for 1.13
Another for 17.03-ce
Canonical and Docker Inc collaborate to develop this snap and it’s released by Docker Inc in the store. https://uappexplorer.com/app/docker.docker-inc
Thanks in advance.
We follow the similar release cycle that Docker Inc runs for the quarterly release.
In general, a quarterly release will be maintained for 4 months. Also it gives people one month window to update from one version to the next.
Here is the illustration of release cycle used by Docker Inc.
Our plan is to request a new track every time a quarterly release comes out. I’m not sure if it’s little bit overkilled on store end.
So the track format will be like new YY.MM versioning scheme that Docker Inc used.
ce stands for community edition.
Ideally, we have multiple tracks in the store as we go. Of cause, we might release newer version of the snap on each track due to regular maintenance(4 months).
We’re about the publish the first quarterly release. The work is almost completed.
Could you create a new track called “17.03-ce” for docker-snap?
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.
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?
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.
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.
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.
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.
@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.
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.
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?