Thanks for the suggestions, @Ads20000 and @roadmr! As of now, our regular update mechanism only exposes a single ESR channel and moves users automatically when the old ESR major version is no more maintained.
If we had the 60esr, 67esr (and esr) tracks, would it be possible to migrate users who stayed on 60esr to 67esr (or to esr)? I know we can close channels. Can we close tracks too?
FWIW you could have esr and 60esr, with esr holding the latest, and the other letting users decide when to move. OTOH that only makes sense if you support more than one esr at a time.
We usually maintain 2 ESRs 12 weeks a year. In my opinion, it makes sense to have 60esr (alongside esr and maybe 67esr) during these weeks. Afterwards, I think we should close 60esr. We’d prefer to not allow users to freshly install a version that is known to contain security issues.
In that case, in my opinion, your original plan of just having esr and using “candidate” for the next one is the one that’ll be the least surprising to users.
I agree with @chipaca that just an esr track is the way to go. If you have 60esr and 67esr there’s no way to make users jump to the newer track when the old one goes entirely out of service. You can close the channels but that doesn’t migrate users to the newer one. You could also release version 67 into the 60esr track but that’ll be confusing for users and in a couple of years, cumbersome to you for having to release the same thing in multiple tracks.
On the other hand I’m quite happy to see that your description of the esr track usage perfectly matches how the feature is implemented 
Cool! I’m glad we found the best strategy for this use case. I wasn’t sure whether esr alone was optimal, at the beginning.
Thanks again for the idea and explanations! I’ll wait until the end of the voting period. Please let me know if you any other suggestions or questions.
+1 on an esr track alone. If we have to introduce per major tracks, let’s please use NN alone instead of NNesr.
We have enough discussion here and seems uncontroversial, so I suggest just moving forward with the track.
As noted in the post right before yours, it was created on April 18th and is now available for use. Example to release revision 1234 (which must already be pushed) to esr/stable:
snapcraft release firefox 1234 esr/stable
Thank you for the creation!
On our end, for the record, we haven’t pushed any release to esr yet. We’ll release it on May 9th (see original post at the top).
With a little bit of delay, Firefox 60.0esr (revision 87) is now available on the esr/candidate channel. Thank you for the help!
I noticed the new track doesn’t appear on the webUI[1]. Should I file a bug on this?
[1] https://dashboard.snapcraft.io/snaps/firefox/revisions/87/release/
This is known, for the time being you can’t use the dashboard web UI to manipulate (i.e. release to) tracks, but support for this is being planned/designed.
If you need to do something that isn’t covered by the current tools (e.g. snapcraft) please let me know and we’ll see how to enable you to do what you need.
Cheers,
Thanks for the quick reply! Is there a public bug I can follow?
Regarding snapcraft, do you know how I can “unrelease” a snap from a channel? I’d like to see if snapcraft release firefox 87 esr works, but I want to make sure I can rollback my changes.
Try this one: https://bugs.launchpad.net/snapstore/+bug/1771148 which would actually be a nice place if you need to describe your use case
You can close the channel. Example:
snapcraft release firefox 87 esr/stable
all looks OK, then:
snapcraft close esr/stable
the channel esr/stable gets closed and the snap becomes unavailable from there.
The esr syntax alone should work, I tested with a track I have and esr in this context should be equivalent to esr/stable.
Looks like I’m missing some permissions:
$ snapcraft close esr/stable
Locale not set! Snapcraft will temporarily use C.UTF-8
Your account lacks permission to close channels for this snap. Make sure the logged in account has upload permissions on 'esr/stable' in series '16'.
I’m using my personal account, which was able to upload the snap earlier today.
Hi Johan,
Sorry! My bad!
I told you (and you did):
snapcraft close esr/stable
but it should be:
snapcraft close firefox esr/stable
(otherwise how does snapcraft know which snap to close a channel for?
I apologize since what you did was follow my (bad) instructions to the letter.
Cheers,
Thanks for the clarification. I should have read snapcraft close --help better too. Speaking of which, snapcraft close should technically require 2 positional arguments. It didn’t enforce it based on the error message in comment 21. I filed a bug to make the error message clearer: https://bugs.launchpad.net/snapcraft/+bug/1771297
Thanks. FYI I marked that as a dupe of https://bugs.launchpad.net/snapcraft/+bug/1735800