Track request for mosquitto

store-requests
#1

Hello,

I’d like to request the creation of two tracks for the Mosquitto snap.

The current versions in the snap store are 1.5.x, and the upstream 1.6.0 has just been released. I would like a 1.5 track to keep the 1.5.x snaps, and a 1.6 track for the 1.6.x snaps, which will also be the same as latest until the next minor release.

Thanks,

Roger

2 Likes
#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 next Friday.

I have three questions before casting my vote.

  1. What’s Mosquitto’s release cadence, how often is a new major version (potentially requiring a new track) released? is this documented somewhere by upstream?
  2. Is there some committment from upstream on maintenance of old versions? e.g. is 1.4 still supported with security updates? will 1.5 continue to be supported now that 1.6 is out, and for how long?
  3. Are new versions backwards-incompatible? meaning, if I was running 1.5 and try to install 1.6, will that just work, or do I need to migrate my data/configuration, or will things break horribly?

Thanks!

  • Daniel
#3

Hi Daniel,

Thanks for responding on 19.04 release day plus one!

  1. It was about 11 months between version 1.5 and 1.6, with 8 maintenance releases for the 1.5 in that time. This was a fairly substantial update though, despite only being a minor release, so other minor updates will be coming along sooner than that. It’s a more a feature based schedule than strict timing at the moment though.

  2. Thus far, maintenance releases have been released for minor versions until the next minor version is available. In addition, security patches are made available for versions that are in repositories for the major distributions, so 1.5.x, 1.4.x, and 1.3.x when it was in Debian stable. There has been the start of discussions in the community about providing ongoing support for 1.5.x, but I don’t know where that will end up at the moment.

  3. We try very hard to follow semantic versioning, so 1.6 should be compatible with everything back to 1.0.

There is a major release on the horizon which will introduce breaking changes, probably after two smaller 1.7 and 1.8 releases. My understanding is that users have to explicitly change between tracks, so I’d prefer to get that the 1.x tracks introduced before then. Please feel free to correct my understanding :slight_smile:

Cheers,

Roger

#4

Hello,

Tracks are meant to separate incompatible versions. If, as you say, 1.6 is compatible with 1.5 and older, then it seems to me you don’t need a track, right?

To put it another way, once 1.6 is out, why would anyone need to install 1.5, if 1.6 will run their code without changes? Further, if 1.6 is out and I get auto-upgraded from 1.5 to 1.6, nothing would break or change from my point of view, correct?

The way you describe it, that eventual hypothetical 2.0-ish release would perhaps need a track (after 1.7 and 1.8 which per what you described would also run all 1.x code correctly and there would be no reason for someone who was running 1.5 to not upgrade automatically to 1.6, 1.7 or 1.8); once 2.0 is out, you would pubish it in latest, which would upgrade everyone (at this point you’d have to put the last 1.x release in, say, a 1.8 track for people who want to stay in the 1.x series, and publicize it so people who choose to stay behind can switch tracks before 2.0 is released).

In general I’m +1 to creating the track you request if you feel it’s necessary, but I wonder if you could read the above and think whether it holds true; if you can think of a reason to separate 1.5 from 1.6 and so on, I think it would be valid to do this with a track.

That said - The 7-day comment period has elapsed and we only have a +1 (contingent to you reading the above and confirming you do want a track) - so I’ll poke our friendly @reviewers for more votes and extend this voting for 3 more days (per Process for aliases, auto-connections and tracks). We’ll check again on Monday!

  • Daniel
#5

I understand what you are saying about compatible versions. However, my experience is that end users can be sticky in what versions they want to work with. I can well imagine people not wanting their embedded systems automatically updating, except for bug fix releases. I’d like to give people the choice of what they think is suitable for them.

#6

Thanks for explaining! OK, I see you’ve given this some thought and I agree - tracks are also about giving the users that choice, so I’ll confirm my +1. I’ll poke reviewers again tomorrow if we don’t get more votes by end of day today.

  • Daniel
1 Like
#7

Hi, @reviewers - Could I get some more eyes/votes on this track request?

Extending review period by another 3 days (May 3rd).

  • Daniel
#8

+1 to grant both tracks

#9

@ralight thanks for your patience and explanations - Mosquitto 1.5 and 1.6 tracks have been created.

Enjoy!

  • Daniel
1 Like
#10

Please forgive me, how I am supposed to release to these tracks? Nothing has changed in the web ui as far as I can see, is it command line only?

#11

Hi!

Apologies - it does look like the first release to a track needs to be done with snapcraft.

snapcraft release mosquitto $REVISION_TO_RELEASE 1.6/stable

After that, I did see some track-related controls appear in the UI (at the top, there’s a “Show revisions released in” -> You can select a track here, and release operations will apply to that track’s risks) - so after a first release using snapcraft, you should be able to manage the track via the GUI.

This does sound like an UI quirk, so I’ll file an issue reporting this and see where it goes.

Cheers,

  • Daniel
#12

Thanks Daniel, I can confirm this works.