Add channels for zookeeper

store-requests
1

Hello,

Can the following channels be added for the zookeeper snap?

  • 3.5.10/stable
  • 3.6.3/stable
  • 3.7.1/stable
  • 3.8.0/stable
2

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.

  1. 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?

  2. 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?

  3. 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
3

We can drop the patch versions if that is what is recommended.

  • 3.5/stable
  • 3.6/stable
  • 3.7/stable
  • 3.8/stable
  • 3.9/stable

There is a 6-month release cycle that is outlined here with minimal detail. In terms of compatibility between patch versions, there seems to be support for it, but I have not personally confirmed that.

4

Thanks!

I’d still need an answer to the main question, let’s rephrase it in terms of only minor versions.

if I was running 3.5 and try to install 3.6, will that just work, or do I need to migrate my data/configuration, or will things break horribly? Similarly, if I have 3.6 and upgrade to 3.7, 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?

From what I saw when skimming the release cycle documentation, upgrades from one minor version to the next are supported. So to rephrase and extend the question: is there a reason why users would want to stay on e.g. 3.8 once 3.9 is out, or is upgrading as soon as possible recommended and supported by zookeeper itself?

Ultimately you as the packager will be responsible for maintaining the snaps, and you know the product (zookeeper) better than I do, so I will base my decision on the information that you give me.

Thanks,

  • daniel
5

Rolling updates are supported between specific minor versions and the next major version. There is better compatibility with upgrading versions if you stop the service first. With a 6-month support cycle, they still provide bug fixes during that time before it goes EOL.

I think it makes sense to have channels for whichever versions they are still distributing which in this case are the versions I mentioned above despite the support cycle.

6

thanks for the replies. I’m +1 on creating the minor-named tracks (no patch versions, those should be handled as updates on each track).

We’ll check back for other replies from @reviewers in a day or two.

  • Daniel
7

+1 to these tracks for zookeeper.

8

Thanks, the 5 requested tracks have now been added.

  • Daniel