306844 - update chrome-versions.sh for trunk and 1.8 branch

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Robert Kaiser]

As long as we had no releases of the code happening, it seemed OK to leave
http://lxr.mozilla.org/mozilla/source/config/chrome-versions.sh untouched, but
now we should update those versions.

We should update MOZILLA_LOCALE_VERSION and MOZILLA_REGION_VERSION to 1.8b4 on
branch and 1.9a1 on trunk, and due to the recent scrollbar stuff that broke all
existing themes, I guess we should even update MOZILLA_SKIN_VERSION to 1.8

Note that those are only used for products using the old (XPFE) chromereg, the
new chromereg handles versioning through EM.
So this is basically a SeaMonkey-only bug (Camino shouldn't care too much).

Comment 1

[Robert Kaiser]

<NeilZZZ> KaiRo: well, sailfish once said that he didn't want it bumped if you
could patch an existing skin to work with the new build without breaking the old
build

Comment 2

[[e-mail]]

CCing Patrick in case he has a preference for a new skin version (if any).

Comment 3

[Patrick Thompson]

In the past, missing stylesheets in older themes were known to cause esoteric 
and cryptic bugs, often blamed on the browser. I just did a quick diff run on 
a the 1.7.11 and recent Seamonkey nightly Modern themes. It seems that 
stylesheets have moved (plugins.css) and new ones added 
(global/nativescrollbars.css, global/xulscrollbars.css, global/neterror.css, 
messenger/start.css, messenger/virtualfolderlistdialog.css). Whether any of 
those, missing from older themes, would cause SM to crash is not known; 
however, it is known that the missing scrollbar stylesheets will negatively 
affect scrollbars.

As such, I think it's a wise idea to bump skinVersion to account for these 
changes, just to be on the safe side. Also, since the changes first came about 
in gecko 1.8, I'd agree that that should be the bump value.

Comment 4

[Robert Kaiser]

At least due to bug 222654, many themes don't show any scrollbars right now, but
yes, we have quite a bunch of other things as well that should recify bumping
from 1.5 to 1.8

Comment 5

[Robert Kaiser]

smfr and pinkerton confirm that Camino only uses in-tree chrome, which works the
same before and after that change, so they don't care about that version stuff
at all. This seems to indicate it really only affects SeaMonkey, and in the way
we want: only langpacks and themes with an updated version will work after the
change, so that we don't get nasty chrome errors from old langpacks/themes.

I'm asking for in-bug r+sr (Neil) and approval-1.8b4 (bsmedberg) for the
following changes:

MOZILLA_[LOCALE|REGION]_VERSION: 1.8b2 --> 1.8b4 (branch) / 1.9a1 (trunk)
MOZILLA_SKIN_VERSION: 1.5 --> 1.8

Comment 6

[Robert Kaiser]

Attachment: branch patch

Branch patch for the usual bump of locale versions and the skin version change
discussed with sailfish here, SeaMonkey-only, low-risk (in-tree locales and
themes keep working as before, 3rd-party packages need to be updated by
maintainers - intentionally)

Comment 7

[Robert Kaiser]

Attachment: trunk patch

And here's the trunk patch for this one.

Comment 8

[[e-mail]]

Comment on attachment 194905 [details] [diff] [review]
branch patch

>+MOZILLA_LOCALE_VERSION=1.8b4
>+MOZILLA_REGION_VERSION=1.8b4
You'll only have to change them again for 1.8b5 :-P

Comment 9

[Robert Kaiser]

> You'll only have to change them again for 1.8b5 :-P

Sure, that's what we have done for every single version in the past (as long as
there were string changes), otherwise users run into chrome errors with old
language packs...

I remember the days when we didn't have it in a central var and I had to do
patches against all locale-affected contents.rdf files in the tree...

BTW, trunk patch is checked in, keeping this open for branch checkin.

Comment 10

[Robert Kaiser]

oops, I should also mark that - checked in on branch as well, FIXED.