Firefox: Please create the track "esr"

[JohanLorenzo]

Hello!

Snap store URL: https://snapcraft.io/firefox

Firefox has an Extended Support Release which may interest medium to large organizations. On this channel, Mozilla provides security patches. The next ESR (60.0esr) will be released on May 9th (but pushed a few days before).

Per the channels documentation, it seems a track would be suited for our case. Next year, when the next ESR major version (likely 67.0esr), we will likely want to have the 60.x.y-esr living on esr/stable and 67.0esr on candidate. That way, system admins can test out the next major version while the rest of the org remains on the stable one.

If I understand the channels documentation correctly, creating a post on this forum is the beginning of the process.

Please let me know if you need more information from me. I’ll be happy to provide it.

[roadmr]

Hello,

Sounds good. If multiple ESRs are expected to coexist, maybe you can use multiple tracks:

60esr/stable has the stable thing,
60esr/{candidate,beta,edge} has test versions not ready to go to stable but based on 60.x

and next year,
67esr/stable and 67esr/{candidate,beta,edge}.

For this, you can benefit from the “fast track” creating procedure, if there’s precedent and the track request follows previous one’s justification we can create them with minimal paperwork.

It’s an idea, but for the time being, since the use case is very well explained and Firefox ESR is quite well-known, I’m +1 on the esr track.

Per the process, we need a waiting period of one week for other reviewers to cast their vote and rationale. I’ll keep an eye on this for the needed votes.

Regards,

• Daniel

[sparkiegeek]

Firefox’s ESR is well known, and provides LTS-like guarantees for its users. +1

[zyga]

+1 from me, many users will welcome this feature

[Ads20000]

60esr/stable has the stable thing,

60esr/{candidate,beta,edge} has test versions not ready to go to stable but based on 60.x

and next year,

67esr/stable and 67esr/{candidate,beta,edge}.

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)?

[JohanLorenzo]

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?

[chipaca]

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.

[JohanLorenzo]

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.

[chipaca]

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.

[roadmr]

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

[JohanLorenzo]

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.

[niemeyer]

+1 on an esr track alone. If we have to introduce per major tracks, let’s please use NN alone instead of NNesr.

[niemeyer]

We have enough discussion here and seems uncontroversial, so I suggest just moving forward with the track.

[roadmr]

I’ve created it. The esr track is now ready for Firefox.

Cheers!

• Daniel

[Reynolds5]

What is the status of this?

[roadmr]

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 esr/stable:

snapcraft release firefox 1234 esr/stable

[JohanLorenzo]

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

[JohanLorenzo]

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/

[roadmr]

I noticed the new track doesn’t appear on the webUI[1]. 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.

Cheers,

• Daniel

[JohanLorenzo]

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.