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:
2.0
3.0
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.
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.
If 2 or 3 makes more sense. Or even 2.x3.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 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!
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.