User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040608 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040608 20040609-cal Help | about gives version 2004040813, should be updated in nightly 20040609 so users can give bug reports with the proper version number. Reproducible: Always Steps to Reproduce: 1. Install nightly 2004-06-09 2. restart 3. help | about Actual Results: Shows version 2004040813 Expected Results: something near 20040609 Number is text in content/about.html.
In CVS it is 2004-04-08 but it should be correct in the xpi. I'll build today and change cvs to 2004-06-15 anyway.
New 2004-06-15 xpis built. about.html updated in cvs.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
Further investigation: installing the calendar_windows_20040609.xpi does produce a reasonable version number (2004060911). But on the download page, the windows 'nightly' link (labeled in html as 2004-06-09) points to calendar_windows_nightly.xpi, and installing this produces the old version 2004040813 as well as old code, so it may be the windows nightly.xpi got reverted somehow. Looking at ftp://ftp.mozilla.org/pub/mozilla.org/calendar/xpi/windows/ in mozilla lists the nightly.xpi as a directory, earlier it listed it as a file with the same date and size and the 20040609.xpi.
Is it possible that the link was cached? Today I pointed calendar_windows_nightly to 20040615. The ftp site should be updated soon and it properly reloaded should give the 20040615 build
Looking at ftp://ftp.mozilla.org/pub/mozilla.org/calendar/xpi/windows/ The nightly.xpi 'folder' was dated 2004-06-14 14:40, so it looked like it got overwritten yesterday. It is dated 2004-06-15 9:55 today after your fix. Retrying produced the old version again, probably from cache. Cleared the cache (preferences | advanced) and retried, this time got the 20040615 version. ...Now it is dated 2004-06-15 14:00 (but it is less than an hour later -- times must be different timezones?). ...Now it is dated 2004-06-15 14:45. Cleared cache again, and retried, this time I got the 20040609 version. ...Now it says 2004-06-15 10:00. Cleared cache again, retried, now I get the 20040615 version. Each time the file listing also listed a 20040615 version just before the nightly version. Maybe there's a mirroring/replicating service that doesn't expect old files to be updated? (or somehow fails with links or whatever is producing the 'folder' icon?) One solution might be to have the download page "nightly" links point to the latest *dated* xpi, so the URL will change every time. The html text currently includes a date that needs to be udpated, so changing the url is not much more.
"_nightly" changed to actual date. Also added <meta http-equiv="expires" content="0"> as per sipaq's suggestion to make the page reload each time and not be cached.
The bugspam monkeys have been set free and are feeding on Calendar :: Sunbird Only. Be afraid for your sanity!
QA Contact: gurganbl → sunbird
You need to log in before you can comment on or make changes to this bug.