Closed
Bug 219566
Opened 21 years ago
Closed 21 years ago
Wrong link to Release Notes in mozilla1.5rc1
Categories
(SeaMonkey :: UI Design, defect)
Tracking
(Not tracked)
VERIFIED
DUPLICATE
of bug 219694
People
(Reporter: piskozub, Unassigned)
References
()
Details
(Keywords: useless-UI)
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.5) Gecko/20030916 Build Identifier: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.5) Gecko/20030916 The link to http://www.mozilla.org/releases/mozilla1.5b/ should be replaced with http://www.mozilla.org/releases/mozilla1.5rc1/ Same thing must be done before rc2 and the final 1.5 release. Reproducible: Always Steps to Reproduce: 1. Choose Help -> Release Notes 2. Use your eyes and brain 3. Be surprised Actual Results: Release notes for mozilla1.5b appear Expected Results: Release notes for mozilla1.5rc1 shoul be linked instead.
Reporter | ||
Comment 1•21 years ago
|
||
Changing to a component which has blocking1.5 flag :-(
Component: User → Tracking
Product: Documentation → Browser
Target Milestone: --- → mozilla1.5final
Version: unspecified → Other Branch
Reporter | ||
Updated•21 years ago
|
Flags: blocking1.5?
Reporter | ||
Updated•21 years ago
|
Component: Tracking → Browser-General
Summary: Wrong link ro Release Notes in mozilla1.5rc1 → Wrong link to Release Notes in mozilla1.5rc1
Reporter | ||
Comment 2•21 years ago
|
||
Changing component to Browser-General
Assignee: rudman → general
QA Contact: rudman → general
Target Milestone: mozilla1.5final → ---
Comment 3•21 years ago
|
||
->XP Apps/GUI (based on previous bug of the same nature, bug 150900) Not a development blocker.
Assignee: general → guifeatures
Severity: blocker → major
Component: Browser-General → XP Apps: GUI Features
Comment 4•21 years ago
|
||
The problem here is that the user-agent still says 1.5b, and so the new code checked in in bug 150900 still thinks you are running a copy of 1.5b. This is not unreasonable. The idea is that, eventually, you update the build number in a single place and everything changes to match. However, if you fail to update the build number in that place, you can't really complain if nothing changes. For release candidates, it seems wise to me to update the user agent to be the final one, and use the same URL for the release notes of the release candidates as for the final release. So, we need to make that change before rc2. It could be argued, of course, that we should have communicated the consequences of bug 150900 more widely. :-) Gerv
Comment 5•21 years ago
|
||
eh, wait, the change in said bug makes it so that the version that is mentioned in milestone.txt is used. that _should_ have been updated in 1.5rc1, imho, as should've been the useragent.
Comment 6•21 years ago
|
||
It seems that that the user agent string does show "1.5" (see the UA string in the report here), but the link goes to the 1.5b notes, so I guess it has been updated in some places and not others. "However, if you fail to update the build number in that place, you can't really complain if nothing changes." Who is "you"? The people that failed to update the build number are not the same as the people "complaining". If you are going to dismiss reasonable bug reports as complaints, you're not going to encourage people to report bugs.
Reporter | ||
Comment 7•21 years ago
|
||
Gervase: The problem is we risk shipping filnal mozilla1.5 with Help -> Release Notes pointing to a document relevant for a historic release. A few days you (gerv) changed the link from the safe http://www.mozilla.org/releases/ to the specific (but now wrong) relnotes page itself. Why doesn't your patch use general.useragent.misc value?
Reporter | ||
Comment 8•21 years ago
|
||
At this moment $srcdir/config/milestone.txt in both MOZILLA_1_5_BRANCH and HEAD (trunk) says (after a few comment lines): 1.5b As MOZILLA_VERSION is created from this very file, we risk shipping not only mozilla1.5 but also mozilla1.6a with the wrong Release Notes. Is there a way to use general.useragent.misc value during the build, instead? (the variable UserAgent version actually displays)
Comment 9•21 years ago
|
||
> Why doesn't your patch use general.useragent.misc value?
Because it uses the canonical value for the build process. If that value hasn't
been changed, it's a bug which needs filing as a blocker. You can either morph
this one or file a new one. Definitely file a new one for the 1.6 trunk.
Gerv
Reporter | ||
Comment 10•21 years ago
|
||
I filed bug 219694 for milestone.txt in MOZILLA_1_5_BRANCH and bug 219695 for trunk. I still believe that linking the Release Notes to MOZILLA_VERSION is wrong as there is and probably won't be a MOZILLA_VERSION=1.5rc2
Reporter | ||
Comment 12•21 years ago
|
||
This bug will hit us again with rc2 both if MOZILLA_VERSION is updated to 1.5 and if it stays as 1.5b. That is if the rc2 release notes URL will end with /mozilla1.5rc2 (different from MOZILLA_VERSION). However, it will be OK in the final 1.5 release when bug 219694 (blocking1.5+) is fixed. Therefore you can close this bug now if you want, but I am sure that using MOZILLA_VERSION automatically as the final part of the Release Notes URL will haunt us again.
Updated•21 years ago
|
Keywords: useless-UI
Comment 13•21 years ago
|
||
> Who is "you"? The people that failed to update the build number are not the > same as the people "complaining". Not "you" specifically; "you" in the sense of "one". As in "If one forgets to update..." I'm not dismissing this bug report. It's obviously a problem. However, the fix is not to back out the link, the fix is to update the version to match reality. The rc1, rc2 and final release notes should all be (IMO) at the URL: http://www.mozilla.org/releases/mozilla1.5/ The correct procedure, therefore, is to update MOZILLA_VERSION on both branches as soon as we branch. Gerv
Comment 14•21 years ago
|
||
> The correct procedure, therefore, is to update MOZILLA_VERSION on both branches
> as soon as we branch.
Sure. I don't think anyone would argue that it's the correct thing to do in
theory. The problem is that it doesn't happen in practice.
Anyway, if the decision is made, I guess this bug is done with - WONTFIX (so it
could be duped to if and when it happens in future)? or a dupe of the version
change bug?
Comment 15•21 years ago
|
||
I've attached patches to both of the version update bugs. Gerv *** This bug has been marked as a duplicate of 216964 ***
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
Comment 16•21 years ago
|
||
Gerv: I think you duped to the wrong bug...
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Comment 17•21 years ago
|
||
*** This bug has been marked as a duplicate of 219694 ***
Status: REOPENED → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → DUPLICATE
Comment 18•21 years ago
|
||
Oops - touch of lysdexia there. Gerv
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•