535304 - mobile release automation should be bumping mobile-browser versions

Status: RESOLVED FIXED

(Release Engineering :: General, defect)

Description

[[e-mail] (:bhearsum)]

Currently, the automation relies on sourceRepoRevision version to have the "release" version number (eg, 1.0 instead of 1.0pre). We shouldn't rely on that. Rather, we should bump confvars.sh in bumpFiles and version-bump.pl should be updated to be able to bump it. There may be additional complication due to the fact that we have different version numbers on different mobile platforms.

Comment 1

[Aki Sasaki (not active)]

This is going to be more of a priority as the mobile team now wants the release branch version number to differ from the nightly version number.

I suppose the workaround is to run a tag step via force build (so no dependent schedulers fire), land the version bump manually, and then sendchange with a dummy tag factory.

Comment 2

[[e-mail] (:bhearsum)]

Can we try to fix this bug instead of working around it? All that needs to be done is add confvars.sh support in version-bump.pl, and then adding that file to the bumpFiles list.

Comment 3

[Aki Sasaki (not active)]

There is currently confusion as to whether the winmo version should be the same, or different, in confvars.sh on release branches.

If it should and/or can be the same, I need to update version-bump.pl to handle global search-and-replace (s/from/to/g); if I need to leave the winmo version alone, I can:

a) multi-line regex (s/from/to/s), or
b) add a different comment to the end of each line that allows me to differentiate the two.

Comment 4

[Aki Sasaki (not active)]

cc'ing [e-mail] for comment #3

Comment 5

[Aki Sasaki (not active)]

Attachment: bump both versions

This works on both versions.

Because of the way version-bump.pl is written (only reading the file one line at a time, and applying the regex to that line), multi-line regexes require a larger patch.

Now that I think about it, we probably *need* winmo versions to be the same on the relbranch for my upcoming winmo release factories to work.

If we absolutely have to only update the maemo version,

  s/(\s\*\)\s+MOZ_APP_VERSION=)\S+/$1$appVersion/s

updates just the default case MOZ_APP_VERSION, should we have the entirety of the file in a scalar.  I'll have to replace the while(<INFILE>) {} and do more testing, however.

My perl-fu isn't completely gone....  Perl hacking is like riding a bike: all special characters and regexes.

Comment 6

[Aki Sasaki (not active)]

Attachment: maemo bump only

A bit more complex, no?
Tested on confvars.sh, should test on all other file types.

Comment 7

[Aki Sasaki (not active)]

Attachment: maemo bump only: remove errant /s

Comment 8

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #3)
> There is currently confusion as to whether the winmo version should be the
> same, or different, in confvars.sh on release branches.

I think that ideally we want the ability to only bump only one or the other on a given relbranch (in addition to bumping both), since their release schedules aren't currently in sync.

On the other hand, I suppose we don't care too much about the version number for winmo on a relbranch that it won't release from... still feels a bit icky though :)

Comment 9

[[e-mail] (:bhearsum)]

Comment on attachment 421206 [details] [diff] [review]
maemo bump only: remove errant /s

Hrmmm, this problem is tougher than it seemed at a glance.

I think this problem is much easier solved by changing around mobile-browser slightly. Pending approval from the mobile folks, I'm going to suggest that we change:
case "$target" in
*-wince*)
    MOZ_APP_VERSION=1.0a4pre
    ;;
*)
    MOZ_APP_VERSION=1.1a1pre
    ;;
esac

to:
*-wince*)
    . wince-version.txt
    ;;
*)
    . maemo-version.txt
    ;;


This would be more in line with existing version files, and make our scripts much more compatible.

If we do this, this problem simply becomes appending an extra file to bumpFiles and adjusting:
    91     my $versionTxt = catfile($appName, 'config', 'version.*\.txt');
to work with additional file names.

I ping'ed Gavin and he told me it's unlikely that we'll need to ship wince and maemo from the same relbranch with different versions, so I believe this will work.

Comment 10

[Aki Sasaki (not active)]

I was thinking along similar lines.

One argument against multiple files is we'll end up syncing winmo and non-winmo at some point, and we'll either end up with 2 of the same file or need to remove one. Also, the "maemo-version" is for mobile desktop as well.

We could fix this via

WINMO_VERSION=1.0a4pre
case "$target" in
*-wince*)
    MOZ_APP_VERSION=$WINMO_VERSION
    ;;

which doesn't match the VERSION_REGEXP, and lets you figure out what the WINMO_VERSION equivalent is when we're building for a non *-wince* $target (if we need to know that for some reason).

Alternately, if it's unlikely we'll ship winmo and maemo from the same branch, the first patch works, no?

Comment 11

[[e-mail] (:bhearsum)]

(In reply to comment #10)
> I was thinking along similar lines.
> 
> One argument against multiple files is we'll end up syncing winmo and non-winmo
> at some point, and we'll either end up with 2 of the same file or need to
> remove one. Also, the "maemo-version" is for mobile desktop as well.
> 
> We could fix this via
> 
> WINMO_VERSION=1.0a4pre
> case "$target" in
> *-wince*)
>     MOZ_APP_VERSION=$WINMO_VERSION
>     ;;
> 
> which doesn't match the VERSION_REGEXP, and lets you figure out what the
> WINMO_VERSION equivalent is when we're building for a non *-wince* $target (if
> we need to know that for some reason).

I *almost* proposed this exact solution, except that we actually don't match against a *specific* old version, we we'd end up bumping anything matching:
my $VERSION_REGEXP = '\d\.\d[\d\.]*' # A version number 
                   . '((a|b)\d+)?'   # Might be an alpha or beta
                   . '(pre)?';       # Might be pre

> Alternately, if it's unlikely we'll ship winmo and maemo from the same branch,
> the first patch works, no?

It does, but it seems silly to force everything to go multi-line when most things aren't. To me, it seems better to sync up where/how we store version numbers.

Comment 12

[Aki Sasaki (not active)]

(In reply to comment #11)

> I *almost* proposed this exact solution, except that we actually don't match
> against a *specific* old version, we we'd end up bumping anything matching:
> my $VERSION_REGEXP = '\d\.\d[\d\.]*' # A version number 
>                    . '((a|b)\d+)?'   # Might be an alpha or beta
>                    . '(pre)?';       # Might be pre

No, I mean search for MOZ_APP_VERSION=$VERSION_REGEXP

> It does, but it seems silly to force everything to go multi-line when most
> things aren't. To me, it seems better to sync up where/how we store version
> numbers.

I'm referring to this patch:
https://bug535304.bugzilla.mozilla.org/attachment.cgi?id=421201

Gavin is objecting above due to "ickiness" but I think keeping these versions artificially apart is going to cause ickiness any way you slice it.

Comment 13

[[e-mail] (:bhearsum)]

(In reply to comment #12)
> (In reply to comment #11)
> I'm referring to this patch:
> https://bug535304.bugzilla.mozilla.org/attachment.cgi?id=421201
> 
> Gavin is objecting above due to "ickiness" but I think keeping these versions
> artificially apart is going to cause ickiness any way you slice it.

I don't think separating the versions to separate files, while they're different, is very icky. And I definitely think it's much better than bumping both. If we have release branches that have tags like FENNEC_1_0rc2_RELEASE, and both the wince and maemo versions are set to 1.0 it can easily be misconstrued that we're shipping wince 1.0rc2.

I know this is a little bit more work since it isn't written yet, but it's a cleaner solution IMHO.

Comment 14

[Aki Sasaki (not active)]

Attachment: move versions out of confvars.sh, into *-version.txt

I'm hoping/assuming ${srcdir} and ${MOZ_BUILD_APP} are accessible at this point.
My loaner laptop doesn't seem to be able to make -f client.mk configure; I'll try on a different box.

Comment 15

[Aki Sasaki (not active)]

Attachment: version-bump.pl patch to update *-version.txt

Comment 16

[Aki Sasaki (not active)]

Attachment: add default-version.txt to release_mobile_master bumpfiles

Comment 17

[[e-mail] (:bhearsum)]

Comment on attachment 421336 [details] [diff] [review]
version-bump.pl patch to update *-version.txt

Please define the filename at the top of the function with the rest of them. r=bhearsum with that change.

Comment 18

[Aki Sasaki (not active)]

Comment on attachment 421335 [details] [diff] [review]
move versions out of confvars.sh, into *-version.txt

Ok, a full build+package after nuking objdir and adding this patch worked -- 1.1a1pre tarball, fennec_1.1a1~20100113115504_armel.deb

Comment 19

[Aki Sasaki (not active)]

Comment on attachment 421335 [details] [diff] [review]
move versions out of confvars.sh, into *-version.txt

http://hg.mozilla.org/mobile-browser/rev/9358800b9223

Comment 20

[Aki Sasaki (not active)]

Attachment: version-bump, with bhearsum's suggested changes

Attaching updated version-bump.pl diff for completeness; carrying over r+.

Comment 21

[Aki Sasaki (not active)]

Comment on attachment 421509 [details] [diff] [review]
version-bump, with bhearsum's suggested changes

http://hg.mozilla.org/build/tools/rev/efcafa9f6ad5

Comment 22

[Aki Sasaki (not active)]

Comment on attachment 421338 [details] [diff] [review]
add default-version.txt to release_mobile_master bumpfiles

http://hg.mozilla.org/build/buildbot-configs/rev/3c945da5ccba