User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11) Gecko/20060202 Firefox/18.104.22.168 Build Identifier: "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124) Gecko/20060202 Firefox/126.96.36.199", build ID:2006020204 Clicking on the big fat link (labeled "Firefox 188.8.131.52") under the Firefox logo leads to 1.5 release notes, not 184.108.40.206 release notes. Reproducible: Always Steps to Reproduce: 1. Type "about:" (without the quotes) in URL bar 2. Hit Enter -- the "about:" page displays 3. Click on the link saying "Firefox 220.127.116.11" between the Firefox logo and the User-Agent string Actual Results: Release notes for 1.5 display: http://www.mozilla.com/firefox/releases/1.5.html Expected Results: Release notes for 18.104.22.168 should display: http://www.mozilla.com/firefox/releases/22.214.171.124.html (Typing this URL into the URL bar shows that there is a page at that address).
Reassigning this one to Rafael, CC Axel. Updating the URL means a localization hit probably, and I wonder if that's what we really want to do anyway. Shouldn't the release notes stay in the same place and simply have updated sections at the top for the new releases? "Firefox 126.96.36.199 released to fix security bugs <link to vuln pages>" The 188.8.131.52 release notes are pretty thin and we hope future 1.5.0.x changes shrink even more. And coming at it from the other side of the coin, someone who's jumped on the bandwagon at the 184.108.40.206 point will now miss the top chunk of information that was in the 1.5 release notes. Then of course it's followed by duplicated System and installation information. Best to "fix" this bug by making the current URL the correct one without having to change any code. But Rafael's call (as perhaps influenced by Axel's concerns)
(In reply to comment #2) > Best to "fix" this bug by making the current URL the correct one without having > to change any code. > > But Rafael's call (as perhaps influenced by Axel's concerns) Agreed on Rafael's call, but I think it should be changed. Actually, the right way to do this is to come up with a schema that is followed to release notes, and generate this URL based on that; we shouldn't need to update this every release. But having a predictable URL lets us play games on the server side if we ever need to. I think it's confusing to have a 1.5.0.x build, and get 1.5 release notes (even if they're updated).
(In reply to comment #3) [...] > But having a predictable URL lets us play games on the server side if we ever > need to. I think it's confusing to have a 1.5.0.x build, and get 1.5 release > notes (even if they're updated). > ... especially since 1.5 and 220.127.116.11 correspond to separate code branches, with separate sets of nightlies (see http://ftp.mozilla.org/firefox/nightly/latest-mozilla1.8/ and http://ftp.mozilla.org/firefox/nightly/latest-mozilla1.8.0/ -- plus similar l10n builds). Both of them were updated less than 24 hours ago.
(In reply to comment #3) > I think it's confusing to have a 1.5.0.x build, and get 1.5 release > notes (even if they're updated). The URL would say "1.5" but who's really going to notice that? the content would start off with the latest 1.5.0.x stuff and say the latest version. 18.104.22.168 *is* a version 1.5 release, there should be absolutely no functional difference between the two to the casual observer. * This helps cut dev work necessary for security updates * Reduces required l10n work tremendously (unless, as it appears, they just leave their URL not updated, which is what I'm proposing en-US do). * Reduce QA work to make sure the URL is updated correctly (still have to check that the content changes land) * Eliminates worry about where the "more details" link in the update dialog should point -- don't need to update it, just point at the release notes. * Bonus: someone using an old version to visit the release notes would see the new version number there, and could even be given a sniff-driven warning box at the top that they need to upgrade (in case they've turned off update checking). As long as the new version's content doesn't replace any of the old content (for that same base version; 1.5 would still completely replace 1.0) but is merely added to the top we're not losing any history value. I guess that's not how we handled the 1.0.x series though, and the release notes menu item has been updated to point at the new location.
Seconding dveditz here. Plus, if we add an ever-changing URL to the language packs, we need to patch them for each of our non-l10n-impact releases, thus adding the whole patch logic to the download size of the incremental update. I really prefer a server-side solution for this. I guess it'd be good to wiki out some of the requirements here, and alternative solutions. Anybody got a good idea for where to hook that up? Topics include l10n, disabling js and whatsnew-like pages, real server negotiated redirect, where to, who etc. And this is not just for release notes. Adding beltzner, I'm not sure if that link should actually go to release notes from a UE pov in the first place.
I'm trying to flush out trademark review via this document: http://wiki.mozilla.org/L10n:Firefox_Trademark_Review We can put some of the requirements there. I do agree that maybe we should consider pointing that link to something else. I don't agree on the release notes being one release note page and adding to it as we have new releases. We've gone down that path before. The release notes url will remain predictable: http://www.mozilla.com/firefox/releases/[version #].html I guess the question is how do we get that page localized?
I'm not that much concerned about where the release notes are actually hosted, but I would prefer to not include that URL in the build, but rather have a server side redirect to it. Esp for things like release notes, I'd like to get out of the corner of all-or-nothing and not having to decide whether we can localize the content or not three weeks before release. Having something dynamic on the server sounds much more appropriate, maybe even something like http://www.mozilla.com/redirect?key=releasenotes&version=22.214.171.124&lang=ab-CD
(In reply to comment #7) Seconding preed. Firefox "knows" if it should call himself "1.0.7", "1.5", "126.96.36.199", or whatever, doesn't it? So why not build up the URL from smaller building blocks, where one part would be "1.5" "188.8.131.52" etc.; if different URLs are needed for different languages, then another part would be "en_US" "fr_BE" "zh_TW" etc. (or maybe the page itself can determine which language it should display); most would be constant even across releases. Once streamlined, the only change from one version to the next would be writing the new "release notes" page, which is already done anyway. No need to ever-repatch the URL itself since the building blocks are already there, they are assembled in a constant manner, and _their_ values already need to be changed (in a predictable way) for other reasons. If a single page must do double duty for more than one release, then the target of one of the URLs can always be a redirect (zero-seconds refresh or whatever).
I've already fixed this in bug 318991 for the trunk and the 1.8.1 branch. about: now links to http://www.mozilla.com/firefox/releases/__MOZ_APP_VERSION__.html, like the Release Notes menu item in the Help menu already does on the 1.8.0 branch (http://lxr.mozilla.org/mozilla1.8.0/source/browser/base/content/utilityOverlay.js#443). So I'd suggest to check in the patch from bug 318991 on the 1.8.0 branch as well, and fix the brand.dtd in all locales by search-and-replace. Concerning multiple languages, that can be solved server-side with content negotiation, so that the link to foo.html results in foo.html.AB, depending on the Accept-Language header; if foo.html.AB is not available, use foo.html.en as a fallback. http://httpd.apache.org/docs/2.0/content-negotiation.html
->Gavin Can you check in the patch that was applied on the trunk?
Created attachment 212963 [details] [diff] [review] patch for the 1.8.0 branch
veto, this busts all l10n builds. I reopened bug 318991, too, as that patch is a semantic change to the entity and should change its key.
Comment on attachment 212963 [details] [diff] [review] patch for the 1.8.0 branch Argh, sorry, this clearly won't do for the 1.5.0 branch since it's involves a localization change (making other localizations URLs invalid).
Given the fact that this is a minor issue (is there even a way to get to about: without knowing about it beforehand?) and involves localization changes to fix correctly, I think this should be WONTFIX for 184.108.40.206, at least on the client side. Bug 318991 handles doing this correctly on the 1.8 branch and trunk, and a server-side redirect or re-shuffling of the release notes mentioned in previous comments can be used if this really is determined to be an issue for 1.5.0.x.
If you go to the release notes from the "release notes" help menu item you get the correct page. The about: page is obscure hidden functionality and is not worth the l10n pain. If Rafael doesn't want to go for a content change as in comment 2 and comment 6 (or a server UA sniff) then this bug isn't appropriate for the 1.5.0.x branch.
Going to mark this WONTFIX for the 1.5.0.x branch. A solution to bug 318991 covers the 2.0 branch and trunk. Feel free to re-open if there's disagreement.