Closed Bug 724311 Opened 9 years ago Closed 8 years ago

Start page JS (upgrade nagging) fails to identify 2.10a1 nightly correctly

Categories

(SeaMonkey :: Website, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: InvisibleSmiley, Assigned: InvisibleSmiley)

Details

2.10a1 nightlies trigger wrong JS checks. To work around that, I'm introducing an "a1" check for rapid release train nightlies. If the checks fail for 2.10a2 (Aurora) or 2.10b1, we'll see then and make that a different bug.

I'm also doing some cleanup, but the core part is this:

<       if (smver[1].match(/^[\d\.]+[ab]\d*$/)) {
---
>       // however, rapid release train nightlies end with a1
>       const prerel_parts = smver[1].match(/^[\d\.]+([ab]\d*)$/);
>       if (prerel_parts && prerel_parts[1] != "a1") {

The code then enters the "else" branch which makes a build date comparison.
Checking in index-test.en.html;
/www/seamonkeyproject-org/src/start/index-test.en.html,v  <--  index-test.en.html
new revision: 1.10; previous revision: 1.9
done
Checking in index.de.html;
/www/seamonkeyproject-org/src/start/index.de.html,v  <--  index.de.html
new revision: 1.18; previous revision: 1.17
done
Checking in index.en.html;
/www/seamonkeyproject-org/src/start/index.en.html,v  <--  index.en.html
new revision: 1.31; previous revision: 1.30
done
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
So, Aurora is affected, too, beta should be OK. Contrary to comment 0, I'll fix it here right away since it's so easy (trunk is a1, Aurora is a2, and the else branch performs a date check against the Gecko build date).

--- index.en.html       4 Feb 2012 22:38:39 -0000       1.31
+++ index.en.html       1 Apr 2012 09:33:34 -0000
@@ -76,9 +76,9 @@
       displayElement("unstablenote", true);
 
       // prereleases have a version number with a/b in it, possibly digits afterwards
-      // however, rapid release train nightlies end with a1
+      // however, with the rapid release train, nightlies end with a1 and Aurora builds with a2
       const prerel_parts = smver[1].match(/^[\d\.]+([ab]\d*)$/);
-      if (prerel_parts && prerel_parts[1] != "a1") {
+      if (prerel_parts && prerel_parts[1] && rerel_parts[1][0] != "a") {
         // check for version number and display a warning and download box if we have a newer version
         const curbeta = "[% betaversion %]";
         const curbeta_parts = curbeta.split(".");

Checking in index-test.en.html;
/www/seamonkeyproject-org/src/start/index-test.en.html,v  <--  index-test.en.html
new revision: 1.11; previous revision: 1.10
done
Checking in index.de.html;
/www/seamonkeyproject-org/src/start/index.de.html,v  <--  index.de.html
new revision: 1.19; previous revision: 1.18
done
Checking in index.en.html;
/www/seamonkeyproject-org/src/start/index.en.html,v  <--  index.en.html
new revision: 1.32; previous revision: 1.31
done
Note that we should also care to switch the page to use navigator.buildid instead of taking the build ID from the UA string, as we very well might be switching away from having it in the UA at all in the future.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #3)
> Note that we should also care to switch the page to use navigator.buildid

FTR: ITYM navigator.buildID.

> instead of taking the build ID from the UA string, as we very well might be
> switching away from having it in the UA at all in the future.

And you think the FF devs will leave it in the JS object?

Apart from that, I don't know what the initial reasons were for using the UA string instead of navigator.buildID in the first place. Do you expect any issues if we switch the logic toward querying navigator.buildID (I mean beyond cutting the return value down to what we need)?
(In reply to Jens Hatlak (:InvisibleSmiley) from comment #4)
> > instead of taking the build ID from the UA string, as we very well might be
> > switching away from having it in the UA at all in the future.
> 
> And you think the FF devs will leave it in the JS object?
> 
> Apart from that, I don't know what the initial reasons were for using the UA
> string instead of navigator.buildID in the first place. Do you expect any
> issues if we switch the logic toward querying navigator.buildID (I mean
> beyond cutting the return value down to what we need)?

navigator.buildID has been introduced for the reason that if we do that it's easy to remove from the UA as sites still have something else to use. That variable hasn't been in existence back when the code we have on /start was written.
I'm reopening this as I think you didn't test it.

You have rerel_parts instead of prerel_parts in this one. Neil found this one.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Well yes, I only checked that there was no warning box with Aurora anymore...

fixed typo

Checking in index-test.en.html;
/www/seamonkeyproject-org/src/start/index-test.en.html,v  <--  index-test.en.html
new revision: 1.12; previous revision: 1.11
done
Checking in index.de.html;
/www/seamonkeyproject-org/src/start/index.de.html,v  <--  index.de.html
new revision: 1.20; previous revision: 1.19
done
Checking in index.en.html;
/www/seamonkeyproject-org/src/start/index.en.html,v  <--  index.en.html
new revision: 1.33; previous revision: 1.32
done
Status: REOPENED → RESOLVED
Closed: 9 years ago8 years ago
Resolution: --- → FIXED
Sorry, but now it fails to recognize 2.9.1 as a valid build and recommends to get build 1.1.16 !!
screenshot 
https://www.wuala.com/openseo/Photos/screenshots/seamonkey%20home.png/?key=CyxQXNwRj2oV
(In reply to Olivier Vit (just a reporter) from comment #8)
> Sorry, but now it fails to recognize 2.9.1 as a valid build and recommends
> to get build 1.1.16 !!

There's (been?) a general website issue, see bug 754109. Check that bug to see whether we're back to normal in general; this bug is fixed once the other one is, too.
Product: Websites → SeaMonkey
You need to log in before you can comment on or make changes to this bug.