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.