Hello,
Per Process for aliases, auto-connections and tracks, we need a 1-week voting/discussion period, so I’ll check back on the discussion and votes in a few days.
I have questions/comments before casting my vote.
We don’t recommend using tracks to segment minor or patch versions. Trying to use tracks to designate major.minor.patch negates many of the advantages of using a snap in the first place and will result in fragmentation of your user base, with people being “stuck” on versions they chose manually and needing manual interaction to explicitly upgrade, even at the minor patch level.
-
Can you explain why this is required for zookeeper? Particularly, are new versions backwards-incompatible? meaning, if I was running 3.5.9 and try to install 3.5.10, will that just work, or do I need to migrate my data/configuration, or will things break horribly? Similarly, if I have 3.6.3 and upgrade to 3.7.1, are things expected to work, or break? Lastly, what is the expectation when e.g. version 4.0 comes out? will that be cleanly upgradeable from 3.x installations or will it imply breaking changes?
-
What’s zookeeper’s release cadence, how often is a new major version (potentially requiring a new track) released? is this documented somewhere by upstream?
-
Is there some commitment from upstream on maintenance of old versions? e.g. are 3.5.x and 3.6.x still supported with security updates? will it continue to be supported now that 3.7.x is out, and for how long?
If there are any questions on what the recommended use of tracks is, I would suggest reading this blog article and its follow-up which explain this a bit more clearly than I can.
Thanks!
- Daniel