Closed Bug 535304 Opened 10 years ago Closed 10 years ago

mobile release automation should be bumping mobile-browser versions

Categories

(Release Engineering :: General, defect)

All
macOS
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bhearsum, Assigned: aki)

References

Details

Attachments

(3 files, 4 obsolete files)

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.
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.
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.
Assignee: nobody → aki
Component: Release Engineering: Future → Release Engineering
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.
Attached patch bump both versions (obsolete) — Splinter Review
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.
Attached patch maemo bump only (obsolete) — Splinter Review
A bit more complex, no?
Tested on confvars.sh, should test on all other file types.
Attachment #421205 - Attachment is obsolete: true
(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 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.
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?
(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.
(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.
(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.
Attachment #421206 - Attachment is obsolete: true
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.
Attachment #421335 - Flags: review?(mark.finkle)
Attachment #421201 - Attachment is obsolete: true
Attachment #421336 - Flags: review?(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.
Attachment #421338 - Flags: review?(bhearsum) → review+
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
Attachment #421335 - Flags: review?(mark.finkle) → review+
Comment on attachment 421335 [details] [diff] [review]
move versions out of confvars.sh, into *-version.txt

http://hg.mozilla.org/mobile-browser/rev/9358800b9223
Attachment #421335 - Flags: checked-in+
Attaching updated version-bump.pl diff for completeness; carrying over r+.
Attachment #421336 - Attachment is obsolete: true
Attachment #421509 - Flags: review+
Attachment #421336 - Flags: review?(bhearsum)
Attachment #421509 - Flags: checked-in+
Comment on attachment 421509 [details] [diff] [review]
version-bump, with bhearsum's suggested changes

http://hg.mozilla.org/build/tools/rev/efcafa9f6ad5
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
Attachment #421338 - Flags: checked-in+
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.