Firefox: Please create the track "esr"

JohanLorenzo 2018-04-17 11:12:29 UTC #6

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 2018-04-17 11:23:13 UTC #7

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 2018-04-17 11:30:40 UTC #8

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 2018-04-17 11:43:43 UTC #9

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 2018-04-17 12:56:17 UTC #10

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 2018-04-17 13:06:21 UTC #11

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 2018-04-18 16:57:07 UTC #12

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

niemeyer 2018-04-18 17:01:39 UTC #13

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

roadmr 2018-04-18 17:12:34 UTC #14

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

Cheers!

Daniel

Reynolds5 2018-04-27 13:30:04 UTC #15

What is the status of this?

roadmr 2018-04-27 13:48:59 UTC #16

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 2018-04-27 14:09:06 UTC #17

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 2018-05-14 15:57:49 UTC #18

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 2018-05-14 16:14:42 UTC #19

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 2018-05-14 16:18:10 UTC #20

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.

roadmr 2018-05-14 16:49:40 UTC #21

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.

JohanLorenzo 2018-05-14 16:56:20 UTC #22

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.

roadmr 2018-05-14 19:42:36 UTC #23

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,

Daniel

JohanLorenzo 2018-05-15 08:22:47 UTC #24

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

sparkiegeek 2018-05-15 09:21:30 UTC #25

Thanks. FYI I marked that as a dupe of https://bugs.launchpad.net/snapcraft/+bug/1735800