219566 - Wrong link to Release Notes in mozilla1.5rc1

Status: VERIFIED DUPLICATE of bug 219694

(SeaMonkey :: UI Design, defect)

Description

[Jacek Piskozub]

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.

Comment 1

[Jacek Piskozub]

Changing to a component which has blocking1.5 flag :-(

Comment 2

[Jacek Piskozub]

Changing component to Browser-General

Comment 3

[Bill Mason]

->XP Apps/GUI (based on previous bug of the same nature, bug 150900)
Not a development blocker.

Comment 4

[Gervase Markham [:gerv]]

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

[Christian :Biesinger (don't email me, ping me on IRC)]

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

[Michael Lefevre]

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.

Comment 7

[Jacek Piskozub]

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?

Comment 8

[Jacek Piskozub]

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

[Gervase Markham [:gerv]]

> 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

Comment 10

[Jacek Piskozub]

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

Comment 11

[Asa Dotzler [:asa]]

not going to worry about this for rc1.

Comment 12

[Jacek Piskozub]

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.

Comment 13

[Gervase Markham [:gerv]]

> 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

[Michael Lefevre]

> 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

[Gervase Markham [:gerv]]

I've attached patches to both of the version update bugs.

Gerv

*** This bug has been marked as a duplicate of 216964 ***

Comment 16

[Andrew Schultz]

Gerv: I think you duped to the wrong bug...

Comment 17

[Malcolm Rowe]

*** This bug has been marked as a duplicate of 219694 ***

Comment 18

[Gervase Markham [:gerv]]

Oops - touch of lysdexia there.

Gerv

Comment 19

[Jacek Piskozub]

Verifying DUP.