At Rocket.Chat we have started releasing more major versions. Some of our users would prefer to stay on a previous version longer. So we would like to introduce two tracks to our rocketchat-server snap:
The idea is we would push the latest snap in the 2.0 series to the 2.0 track. Example if we provide any more patch releases to our current 2.4 release.
Then our new 3.0 release / releases would go on the 3.0 track.
A link to deprecation schedule: https://rocket.chat/docs/getting-support/#supported-versions-of-rocketchat if of use.
Please let me know if any further information is needed or further verification.
+1 from me, the deprecation/release schedule document was super useful and this looks consistent with use of tracks.
We’ll revisit this in a few days to give other @reviewers time to chime in on this request.
+1 from me as well.
If 2.4 ends up in the 2.0 track you might consider calling the track “2” instead, but I still +1 2.0 if you think it best.
I’m not sure what the general pattern is on naming, but I think we’d definitely aim for the latest minor and patch inside of that and when we hit new major that’s when we’d bump up to a new track since thats where breaking changes might be introduced.
3 makes more sense. Or even
3.x that’s fine with me.
the general pattern is whatever allows you to bucket mutually-compatible releases in a single track; ideally users only should need to stay on a specific track if the newest release introduces breaking changes.
So let me know; if you prefer 2 and 3 we can do that; if it’s likely you’ll have breaking changes in 2.x releases then might be needed to split those into separate tracks.
I like the naming of 2.x 3.x.
I think it represents what we are aiming for with our major release cycles. The idea of course is never any breaking changes on anything other then major versions. So only minor and patches would be released to the branch.
In case it’s not obvious, +1 from me on 2.x/3.x. I’m all about enabling the ux developers want for their snaps, I just wanted to share my thoughts!
+1 from me too for whatever you decide is best for you, 2.x/3.x is understandable to your users I imagine
2.x / 3.x I think works for us and our usage.
Please let me know if you need anything else from us. We’d like to get 2.x setup ASAP so we can give our users time to lock in before we release 3.0 so they can hold off the update if they wish.
Wow, a total of +4 votes!
3.x tracks, they’re ready to use now.
Thanks so much everyone! . We will start putting to good use