226377 - localeVersion should be separate from milestone.txt

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

For point releases it's often the case that there are no changes requiring
localization.  (Hopefully we can make this happen for final releases as well,
relative to the beta.)  Thus I think we shouldn't be filling in the locale
version from milestone.txt, but rather from a separately stored number.

It would be quite simple to just put this number in configure.in -- that's the
solution I'm tempted to use for now.  (We could just call it LOCALE_VERSION
instead of MOZILLA_VERSION.)  We could do the same for skin versions as well
(although they should probably be separate for the new and old apps).

Does this seem reasonable?

Comment 1

[Robert Kaiser]

Sounds good, it's one change I do have in my vision for a long-term solution for
this problem :)

We should really have a LOCALE_VERSION and a SKIN_VERSION separated from
MOZILLA_VERSION (though localizers tend to do new localization releases even for
point releases, fixeing bugs in their L10n packs).

Most time we need to change LOCALE_VERSION between beta and final though, as we
have no L10n freeze and usually get in some string changes in the tree freeze
period.

Nayways, the real nice solution would be to also switch from .in files to using
the XUL preprocessor (and use LOCALE_VERSION and SKIN_VERSION there) - but I
don't know how I would set such variables there and use it...

Comment 2

[Benjamin Smedberg]

defines for the preprocessor are the same as C++, using the DEFINES makefile
var. Since this is used all over the tree, we should probably include it in
config.mk for global usage.

--BDS

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch

This adds MOZILLA_LOCALE_VERSION and MOZILLA_REGION_VERSION.  Someone should
check that I made the distinction between language packs and content packs
correctly...

Comment 4

[Robert Kaiser]

Comment on attachment 136386 [details] [diff] [review]
patch

> dnl Get mozilla version from central milestone file
> MOZILLA_VERSION=`$PERL $srcdir/config/milestone.pl -topsrcdir $srcdir`
>+MOZILLA_LOCALE_VERSION=1.6b
>+MOZILLA_REGION_VERSION=1.6b

should we really hardcode those in configure.in?
Shouldn't we have all those versions defined in some sperate file, so that
1) it would be easier to find and change,
2) easier to use a different definition e.g. for FB and/or TB?

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'm planning to add additional variables such as:

TOOLKIT_LOCALE_VERSION
BROWSER_LOCALE_VERSION
etc...

But those aren't automated yet at all.  (And probably likewise for SKIN_VERSION.)

I guess they could be put in a separate file and configure.in could source it...

Comment 6

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

>I guess they could be put in a separate file and configure.in could source it...

maybe a modified milestone.txt?

Comment 7

[Benjamin Smedberg]

I think we're going the wrong way here... imo the preprocessor is a much better
solution to this problem. It's available for immediate use and gives a lot more
flexibility (for example to bump toolkit/app versions separately), and doesn't
require builders to reconfigure when we bump localeVersions.

Comment 8

[Robert Kaiser]

bsmedberg:
true, I'm with you on this. I'll try to play around with that as soon as I've
got time (and that may be a while).

I'm not sure what to do here though. This bug has blocking1.6b+ and r= pending
on the patch. A patch reverting everything to 'normal' files but using the XUL
preprocessor might be too big to get in at this stage.
Should we get this patch in (I'd like better if the version numbers weren't tied
into configure.in though), or should we leave both versions tied to
MOZILLA_VERSION for 1.6 and resolve it the correct way (XUL preprocessor) on 1.7a?

Comment 9

[Benjamin Smedberg]

Comment on attachment 136386 [details] [diff] [review]
patch

Robert and David: I'm fine with a configure-based hack for the purposes of
1.6b/final, but Robert is right; the actual version string must be someplace
other than configure.in

Robert, you or I can get a preprocessor-based version system working after 1.7a
opens.

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch

This uses an external file to store the versions.

Comment 11

[Benjamin Smedberg]

Comment on attachment 136616 [details] [diff] [review]
patch

r=bsmedberg on the build-config stuff; I didn't see problems with the
contents.rdf but I didn't look really hard at them.

Comment 12

[Robert Kaiser]

Comment on attachment 136616 [details] [diff] [review]
patch

This patch looks good to me...
I'd be happy if we could get rid of the distiction of "locale" and "region" in
Mozilla completely, but it looks you caught them the right way. Thanks.

bsmedberg: BTW, can we use those variables in chrome-versions.sh for the XUL
preprocessor approach as well?

Comment 13

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 136616 [details] [diff] [review]
patch

sr=[e-mail]

Comment 14

[Asa Dotzler [:asa]]

Comment on attachment 136616 [details] [diff] [review]
patch

a=asa (on behalf of drivers) for checkin to 1.6beta

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Fix checked in to trunk, 2003-12-02 15:18/22 -0800.