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

Status: RESOLVED FIXED

(Release Engineering :: Release Requests, defect)

Description

[Lukas Blakk [:lsblakk] use ?needinfo]

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

Comment 1

[[e-mail] (:bhearsum)]

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

[Nick McSpadden]

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.

Comment 3

[[e-mail] (:bhearsum)]

(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

[Nick McSpadden]

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.

Comment 5

[[e-mail] (:bhearsum)]

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

Comment 6

[[e-mail] (:bhearsum)]

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?

Comment 7

[Lukas Blakk [:lsblakk] use ?needinfo]

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