All users were logged out of Bugzilla on October 13th, 2018

Please create a "latest-prior-esr" symlink on ftp

RESOLVED FIXED

Status

RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: lsblakk, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

This is a request from the enterprise mailing list:

"a generic "latest-prior-esr" would be useful, as admins could always rely on "latest-prior-esr" & "latest-esr" instead of having to retrieve specific version numbers.  If nothing else, "latest-17.0esr" will not be very helpful twelve weeks from now, whereas "latest-prior-esr" will always be meaningful."
This isn't terribly hard to do, but I question the value. Could someone reiterate the use case or forward the thread to me?

Comment 2

5 years ago
I requested this because it would dramatically improve reliability for admins who use scripts that obtain Firefox updates.  Look at this current use case: Firefox 24.0esr has been released, simultaneously with 17.0.9esr.  Anyone who obtains the "latest-esr" will get 24.0esr. My understanding of the point of 17.0.9esr's existence is to act as a grace period for organizations to test the upgrade to 24.0esr.  Hence, many organizations will want to use 17.0.9esr as a stepping stone - and therefore it will be useful to be able to obtain it automatically in a script.

Currently there is no mechanism to obtain "the latest version of the previous ESR track."  We could write a script that obtains the "latest-17.0esr," but that means we have to rewrite it when 17esr is retired in favor of 24esr.  My goal with this request is to have a reliable location for the latest version of both ESR tracks - current and previous - that doesn't change between various iterations.  Otherwise admins would have to continually modify the script every time the release cycle advances to a new base version of the ESR.  Given that you agree it isn't terribly hard to do, it would make life easier for admins in general because the URLs for getting the latest Firefox ESR versions would never change.
(In reply to Nick McSpadden from comment #2)
> Currently there is no mechanism to obtain "the latest version of the
> previous ESR track."  We could write a script that obtains the
> "latest-17.0esr," but that means we have to rewrite it when 17esr is retired
> in favor of 24esr.

Don't you need to rewrite some things anyways due to the versions in the filenames changing?

Comment 4

5 years ago
Regular expressions can easily account for the latest-esr filename changing, especially on the Mac version.  The format is consistent - "Firefox<vers>.dmg".  

I feel that the fact that we can script around it misses the point, though - having consistent URLs for all "latest" releases of any sort, regardless of date or version, simplifies the process.  If the goal is to accommodate organizations with slower release schedules than Firefox's regular version, such an additional symlink in the "releases" directory could benefit the system administrators.
Turns out our tools don't support creating multiple symlinks. I did this by hand instead, which will need to be changed whenever the next ESR ships:
lrwxrwxrwx  1 ffxbld firefox    14 Sep 20 12:37 latest-prior-esr -> latest-17.0esr
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Someone just pointed out to me that having latest-prior-esr after 17.0esr is EOL'ed might be confusing, and possibly lead people to download an insecure version. Any thoughts on that, Lukas?
Flags: needinfo?(lsblakk)
(Reporter)

Comment 7

5 years ago
(In reply to Ben Hearsum [:bhearsum] from comment #6)
> Someone just pointed out to me that having latest-prior-esr after 17.0esr is
> EOL'ed might be confusing, and possibly lead people to download an insecure
> version. Any thoughts on that, Lukas?

Since "prior" is in the symlink's name, I think we can trust people to understand this isn't _the_ _latest_ release of esr.  If it's no trouble to maintain this link and helps our ESR community with their automation I don't see the harm of having this.
Flags: needinfo?(lsblakk)
You need to log in before you can comment on or make changes to this bug.