Closed Bug 182506 Opened 22 years ago Closed 22 years ago

MOZILLA_1_2_RELEASE is missing some checkins from MOZILLA_1_2_BRANCH

Categories

(SeaMonkey :: Build Config, defect)

Product:
SeaMonkey
Component:
Build Config
Version:
Other Branch
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: malcolm-bmo, Assigned: leaf)

References

Details

Attachments

(1 file)

cvs diff: 1.2 release against tip of 1.2 branch (SeaMonkeyAll only)
36.55 KB, text/plain
Details 
Fixes for at least the following bugs were made into MOZILLA_1_2_BRANCH, but 
have 'disappeared' from MOZILLA_1_2_RELEASE.  That is, these bugs were thought 
to have been fixed in 1.2, but the 1.2 release tag does not include the fixed 
versions, though the 1.2 branch tip does.

Bug 178722: calling Array.sort() on an empty array returns undefined instead of 
an empty array
[venkman fix only]

Bug 124556: Crashing on random pages in 8-bit StaticGray class X11 server
[nsImageGTK::DrawCompositedGeneral]
[bug is critical, crash]

Bug 180339: Can't send message if receiver contain Chinese character

Bug 167663: [OS X]window disappears when clicking the maximize button (green +)
[checkin similar to third attachment, but not identical]

Bug 173195: Changes in the Mozilla/Netscape Installer to run Palm Conduit 
Installer

Were the mozilla.org binaries made against MOZILLA_1_2_RELEASE?
Version: Trunk → Other Branch
All the changes between MOZILLA_1_2_RELEASE and the tip of MOZILLA_1_2_BRANCH.
More details (for that bug only) are available at bug 124556 comment 16 and 
later.
Interesting to note that none of the bugs mentioned appear on the "make Mozilla
1.2 not suck" bug dependency list http://bugzilla.mozilla.org/show_bug.cgi?id=174647

Bug #167663 was removed from the dependency list on 11/20. The others don't
appear to have ever been on the dependency list.

Not all the checkins for 1.2final appeared on the '1.2 not suck' list.

Bug 167663 was removed from the list because a more complete fix was expected 
on the trunk.  See bug 167663 comment 108.
Apropos missing stuff: bug 182550 - Talkback is missing on 1.2 release, Linux
(not explicitly mentioned in the diff)
For the record, I'd think this probably doesn't affect the release builds, since
the (major-platform, anyway) release builds are done from the branch before the
release is tagged (and then tested to see if they're working correctly before
they're considered the release). (Or has someone tested that it does?)
I have pulled MOZILLA_1_2_BRANCH from CVS yesterday as I have documented
at ftp://depot.mcom.com/pub/pioch/mozilla-1.2/  (README file)

The source code obtained is in the tarball mozilla-1.2-branch.source.tar.bz2
at the URL above.

recursive diff with the MOZILLA_1_2_RELEASE as posted on ftp.mozilla.org
gives me about the same as attachment 107704 [details] on this bug

I checked the source code manually; bug 124556 is correctly fixed,
and bug 167493 is correctly backed out, i.e. the TagList starts with an "8"
instead of a "9", cf attachment 98435 [details] [diff] [review]

I've produced a build on Solaris8 (my 4th in 3 days I think :-)
and the result is another mozilla-1.2.sparc-sun-solaris2.8.tar.bz2
posted above.

This build passes basic QA for me :-)
ie it doesn't crash due to patch for 124556 missing,
and I cannot reproduce parser bugs due to bug 167493 tracked in bug 182500
for instance bug 182498 is fixed and attachment 107701 [details] displays the
anchor/link correctly, as expected.

Do we need anything else to ship this as 1.2.1 ?
I'd like to publically thank (or as publically as I can on bugzilla) those who
worked hard to determine the problem with 1.2, and to endico and asa for the
Official Mozilla statement on the problem and for pulling access to 1.2. This
quick reaction is yet another example of customer service that one would never
see from Microsoft and its IE product. And just think, MS staff are paid to
provide service, while Mozilla people aren't (well, some are, but the vast
majority aren't).

Also nice to see all the compliments posted at Mozillazine.
dbaron points out that the user agent is getting revved on the 1.2 branch... so
you might need to rebuild your solaris build.

(also, the binaries are produced just before the tag is made... but it's
possible the tree used for tagging was a few revisions behind).

The 1.2.1 tag/source will not have this issue.
Assignee: seawood → leaf
Ok the original 1.2 release tag is fixed (not including the dbaron fix). Fixing
source tarfiles now while we wait for 1.2.1 builds to test.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
*** Bug 182550 has been marked as a duplicate of this bug. ***
Urk, dont you people want to reconsider in future just changing tarballs ?
We'd like to get the tags, source tarfiles, and binaries to match up. The
binaries had the code, there was no way to re-release those. Tag and source tar
files have been fixed.

updated tarfiles posted 2002/12/1
Just pulled MOZILLA_1_2_1_RELEASE from cvs -- tarball now available off
ftp://depot.mcom.com/pub/pioch/mozilla-1.2.1/

Looks ok so far, only changes with the MOZILLA_1_2_BRANCH source tarball
posted above are:

-1.2
+1.2.1
-MOZILLA_VERSION='1.2'
+MOZILLA_VERSION='1.2.1'
-MOZILLA_VERSION='1.2'
+MOZILLA_VERSION='1.2.1'
-       <string>0.9.7+, <C2><A9> 1998-2002 The Mozilla Organization</string>
+       <string>1.2.1, <C2><A9> 1998-2002 The Mozilla Organization</string>
-       <string>0.9.7+</string>
+       <string>1.2.1</string>
-       <string>1.2, <C2><A9> 1998-2002 The Mozilla Organization</string>
+       <string>1.2.1, <C2><A9> 1998-2002 The Mozilla Organization</string>
-       <string>1.2, <C2><A9>1998-2002 The Mozilla Organization</string>
+       <string>1.2.1, <C2><A9>1998-2002 The Mozilla Organization</string>
-       <string>1.2</string>
+       <string>1.2.1</string>
-       <string>1.2</string>
+       <string>1.2.1</string>
-#define                VERSION_MINOR                   0x20    // revision & fi
x in BCD
+#define                VERSION_MINOR                   0x21    // revision & fi
x in BCD
-#define                VERSION_STRING                  "1.2"
+#define                VERSION_STRING                  "1.2.1"
-Version=1.2.0r.0
+Version=1.2.1r.0
-        0x20,
+        0x21,
-        "1.2",         // short version string
-        "Mozilla 1.2 Installer"        // long version string
+        "1.2.1",               // short version string
+        "Mozilla 1.2.1 Installer"      // long version string

Checking source code manually:
bug 124556 is correctly fixed per attachment 106427 [details] [diff] [review],
and bug 167493 is correctly backed out, i.e. the TagList starts with an "8"
instead of a "9", per attachment 98435 [details] [diff] [review] ...

Building now...
Followup on comment 14 above, doing QA the same way as comment 7:

Build of MOZILLA_1_2_1_RELEASE doesn't crash due to patch for bug 124556 missing,
and I cannot reproduce parser bugs due to bug 167493 tracked in bug 182500
for instance bug 182498 is fixed and attachment 107701 [details] displays the
anchor/link correctly, as expected.

However, my Solaris build displays in HELP | ABOUT:

Mozilla 1.2
Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.2) Gecko/20021203

In other words, the ABOUT section or User-Agent doesn't display the fact
it's version 1.2.1 on Unix (unlike the Win32 version, which displays it
correctly).

Can anyone verify that other Unix builds have the same problem ?
(Linux, anyone ?)

In other words, what I built now on Solaris looks indistinguishible
from the build of the tip of MOZILLA_1_2_BRANCH from comment 7

I'm fairly sure I didn't screwup mixing the sources: a quick glance at
mozilla/configure states MOZILLA_VERSION='1.2.1'

Nicolas: I see the correct version number in about: - using the Linux .tar.gz
package.
It has been a long day and I almost thought I was going nuts, and despite the
fact that I cannot pull MOZILLA_1_2_1_RELEASE from CVS right now as
cvs-mirror.mozilla.org is hosed -- it doesn't even respond to "cvs login"...

I started mozilla on a non-existing profile, selected HELP | ABOUT then quit.
Here are the generated contents of $HOME/.mozilla/default/xxx.slt/prefs.js :

# Mozilla User Preferences
// This is a generated file!

user_pref("browser.startup.homepage_override.mstone", "rv:1.2");
user_pref("prefs.converted-to-utf8", true);
user_pref("timebomb.first_launch_time", "1038948651011347");

I'd be curious to find out what the "override mstone" above is for :-)

Also, every time I delete it and start mozilla, it gets added back...

could that be the culprit for making a 1.2.1 version look like a 1.2
in the HELP | ABOUT MOZILLA page (and possibly, the User-Agent ?)

Nicolas: Do you still get the worng User Agent if you visit one or two different
pages before going to "Help > About Mozilla"? This looks to get only set for the
startup override homepage (The first page that is shown for a given profile with
that version).
I'm also seeing rv:1.2 on the RedHat 8 xft-enabled RPM builds.
The RedHat 8 xft build has been contributed (not built by mozilla.org)
like the Solaris build I am doing.

Could it be that every contributed build, issued from a cvs checkout of
the MOZILLA_1_2_1_RELEASE as per the official instructions,
displays a rv:1.2,

whereas the "official" mozilla.org builds display rv:1.2.1
for instance because they were not make according to the "official instructions"
but the builds were made against the tip of the MOZILLA_1_2_BRANCH ?

PS: that would mean that MOZILLA_1_2_1_RELEASE is still missing some
checkins from the MOZILLA_1_2_BRANCH !

Found it... the above is true, MOZILLA_1_2_1_RELEASE still doesn't correspond
to the tip of MOZILLA_1_2_BRANCH and is missing some checkins, specifically
attachment 107815 [details] [diff] [review] of bug 182812
is correctly checked in MOZILLA_1_2_BRANCH but partially into
MOZILLA_1_2_1_RELEASE

Details of what's different between MOZILLA_1_2_BRANCH
and MOZILLA_1_2_1_RELEASE :

--- MOZILLA_1_2_1_RELEASE/mozilla/modules/libpref/src/init/all.js Wed Nov 13
17:07:23 2002
+++ MOZILLA_1_2_BRANCH/mozilla/modules/libpref/src/init/all.js      Sat Nov 30
11:59:48 2002
@@ -47,7 +47,7 @@
 pref("keyword.enabled", false);
 pref("general.useragent.locale", "chrome://navigator/locale/navigator.properties");
 pref("general.useragent.contentlocale",
"chrome://navigator-region/locale/region.properties");
-pref("general.useragent.misc", "rv:1.2");
+pref("general.useragent.misc", "rv:1.2.1");

 pref("general.startup.browser",             true);
 pref("general.startup.mail",                false);

In other words, MOZILLA_1_2_1_RELEASE has
  pref("general.useragent.misc", "rv:1.2");

while MOZILLA_1_2_BRANCH has
  pref("general.useragent.misc", "rv:1.2.1");

So are the _RELEASE tags hopelessly hosed ?
It looks like the only way for contributors to produce correct builds
is once again to checkout via CVS the tip of the _BRANCH
(which is what mozilla.org is doing, and that explains why only
the official mozilla.org builds display the correct version, rv:1.2.1 !!!)

mozilla-source-1.2.1.tar.bz2 available at
ftp://ftp.mozilla.org/pub/mozilla/releases/mozilla1.2.1/src/

contains the wrong User-Agent rv: and needs to be pulled.
It matches MOZILLA_1_2_1_RELEASE/mozilla/modules/libpref/src/init/all.js with
  pref("general.useragent.misc", "rv:1.2");

(the "src" directory and contributed builds are the only things that
were built against MOZILLA_1_2_1_RELEASE apparently)

The correct source code tarball of what should be MOZILLA_1_2_1_RELEASE
is now posted at
  ftp://depot.mcom.com/pub/pioch/mozilla-1.2.1/

(file mozilla-1.2_BRANCH.src.tar.bz2)

The included file mozilla/modules/libpref/src/init/all.js has the correct
  pref("general.useragent.misc", "rv:1.2.1");

Building this sources (my 7th build!) produces a Solaris8 distribution
of Mozilla 1.2.1 that passes finally my stringent QA process
(comment 15 above)

Updated README and binary distribution posted on
  ftp://depot.mcom.com/pub/pioch/mozilla-1.2.1/
until Dawn pushes them on ftp.mozilla.org

All contributed builds on ftp.mozilla.org and src/ distributions
are currently invalid and will display rv:1.2.1 instead of rv:1.2

Hopefully this should be the end of this saga...
The above should read:
  ...and will display rv:1.2 instead of rv:1.2.1

Maybe people triaging bugs reported on rv:1.2
should be made aware that the User-Agent string is not reliable
for this revision of the Mozilla client.

verified per final comments
Status: RESOLVED → VERIFIED
err... not really, if you read the last comments
the MOZILLA_1_2_1_RELEASE tag was just missing the
rv: patch to increase version to 1.2.1
and nobody ever confirmed this was fixed...

is it?
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: