Hmm, what about the use-case where someone wants to track ESR releases? Would it be too much to have tracks for v60, v67, and esr (where esr releases are pushed to esr/stable as well as e.g. v67/stable when they’re ready)?
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
esr) tracks, would it be possible to migrate users who stayed on
67esr (or to
esr)? I know we can close channels. Can we close tracks too?
FWIW you could have
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
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
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
We have enough discussion here and seems uncontroversial, so I suggest just moving forward with the track.
I’ve created it. The
esr track is now ready for Firefox.
What is the status of this?
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
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. Should I file a bug on this?
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.
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
esr/stable gets closed and the snap becomes unavailable from there.
esr syntax alone should work, I tested with a track I have and
esr in this context should be equivalent to
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.
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.
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