Closed Bug 505491 Opened 11 years ago Closed 11 years ago

Firefox 3.5.x language pack install.rdf needs to stabilize

Categories

(Firefox Build System :: General, defect)

3.5 Branch
defect
Not set

Tracking

(blocking1.9.1 -, status1.9.1 .3-fixed)

RESOLVED FIXED
mozilla3.5
Tracking Status
blocking1.9.1 --- -
status1.9.1 --- .3-fixed

People

(Reporter: Pike, Assigned: Pike)

References

Details

Attachments

(1 file, 1 obsolete file)

Now that Firefox 3.5 is stable, language packs compat information should be switched from "just this milestone" to minVersion 3.5 and maxVersion 3.5.*.

I'd like to make the langpack version something more clever, to be precise, 

3.5 plus the output of 

hg log -l1 --template='.{rev}\n' -q 2>/dev/null

That will yield proper version number bumps whenever we update l10n-changesets. For people working off their own non-hg sources, the version number would just be 3.5. The makefile should support to override that on the command line.

I'll try to create a patch for 1.9.1.2.
blocking1.9.1: ? → -
This is partly what we've done for 3.0.x already, too, we need to hard-code the version numbers for the langpack compat check to 3.5 and 3.5.*.

In addition, I'm introducing a new versioning for the langpack itself, which is going to be 3.5__VERSION_SUFFIX__.

VERSION_SUFFIX can be specified via the make command, like

make langpack-fr VERSION_SUFFIX=a1

or is deduced by the numeric revision of the locale repository, or is empty. If it's undefined, it's empty, thus my use of #expand there in addition to the substitution filter, which errors. The numeric revision is added with a leading dot. So you get 3.5.681 or something.

This will make it much easier to lively develop language packs for new localizations on the one hand, and on the other hand give us the right versioning scheme for language packs generated by the release automation. If l10n-changesets is up'ed, it's going to get a new version number corresponding to the new changeset.

As our releasebuilds always just clone what's on hg.m.o, the numeric revisions should be incremental and pretty deterministic.

Note, I moved from hg log -l1 to hg id --num to make the changeset work, which is a change to my initial comment.
Attachment #390485 - Flags: review?(ted.mielczarek)
This could be interesting for coop and Armen, too.
Duplicate of this bug: 504811
Comment on attachment 390485 [details] [diff] [review]
hardcode min- and maxVersion, deduce minor version from hg if present

+VERSION_SUFFIX = $(addprefix .,$(shell cd $(LOCALE_SRCDIR) && hg identify --num 2>/dev/null))

You don't need the $(addprefix), you can just write .$(shell ...). (addprefix is useful when you want to add that to a list of things.) You might also want to use "hg identify --num --rev .", since that doesn't scan the source tree for changes so it can append a "+" symbol.

-               em:version="@MOZ_APP_VERSION@"
+#expand                em:version="3.5__VERSION_SUFFIX__"

Is this just goofy diff formatting, or do the indentations not line up anymore?
Attachment #390485 - Flags: review?(ted.mielczarek) → review+
The indention in install.rdf is such that the generated install.rdf is properly indented. Either way has its merits, I guess. Any preference, Ted?
Actually, the $(addprefix ) is there to leave the suffix empty if the l10n directory isn't an hg repo, mostly for new locales coming in and not yet with version control.

If the ident fails, .$(shell ) yields a version number of "3.5.", with addprefix, it's just "3.5".
Ok, both of those sound fine then.
Attached patch updated patchSplinter Review
Updated the patch for the backout of l10n.mk, and I do use the --rev . suggestion from Ted.

Carrying over review and requesting approval for .3.
Attachment #390485 - Attachment is obsolete: true
Attachment #393506 - Flags: review+
Attachment #393506 - Flags: approval1.9.1.3?
Comment on attachment 393506 [details] [diff] [review]
updated patch

Approved for 1.9.1.3. a=ss, assuming this doesn't break the build. :)
Attachment #393506 - Flags: approval1.9.1.3? → approval1.9.1.3+
FIXED .3, http://hg.mozilla.org/releases/mozilla-1.9.1/rev/66451cf97c19
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.5
Axel, I just saw the patch and I fail to understand two things:
1) Why hardcode the based Firefox version in multiple places inside the install.rdf, wouldn't it be better to have it in one place in the Makefile instead?
2) Why mix #expand into this when #filter substitution is on in any case and @VERSION_SUFFIX@ would work without #expand?

Apart from that, a solution that doesn't need different handling of stable branches would be nicer...
substitution fails fatally on a non-existing variable, which is right for all other places, but in the case of the version suffix, I prefer fallback to empty, which is what #expand does.

The versioning for non-stable branches doesn't do any good, as you can't specify a working version compat info, thus updates don't make sense. The langpacks are really just for local use, IMHO. That makes me less eager to spread more version numbers.

I hope to carve out language pack generation from the build process, too, to make testing more lightweight still, hard-coding the version compat info makes that easier.
Depends on: 515011
Blocks: 531059
Component: Build Config → General
Product: Firefox → Firefox Build System
Target Milestone: Firefox 3.5 → mozilla3.5
You need to log in before you can comment on or make changes to this bug.