Closed Bug 364589 Opened 18 years ago Closed 17 years ago

Version bump needed for Sunbird nightlies in AUS

Categories

(AUS Graveyard :: Administration, task)

PowerPC
macOS
task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
4.x (triaged)

People

(Reporter: mattwillis, Assigned: morgamic)

References

Details

Since we are beginning to ship trunk vs. branch Sunbird nightlies and their updates via AUS, we need to change some version numbers at
http://lxr.mozilla.org/mozilla/source/webtools/aus/xml/inc/config-dist.php#70
How should the version numbers change?
Status: NEW → ASSIGNED
We need to decide how exactly we're going to do the Sunbird versioning to cope with the AUS quirks first.  Mike, is there a plan for making AUS not assume that all Mozilla applications will be versioned in lock-step?

Matt, can you summarize the discussion we've had up to this point?
I think it's probably best to fix AUS so you can pick your version -- not the other way around.  I filed bug 364628 so we can remove the quirks.  Someone submitted a patch and I will review it today.  The patch looks pretty straightforward but I want to run the acceptance tests before giving it the OK.  Will do that after some addons work.

I would suggest picking the version numbers that work for you.  The AUS code is going to be adjusted to give you that flexibility -- which is the right thing to do long-term.  That should be available tonight or tomorrow -- when did you need these changes by?
Whatever version number we choose, it should be less then 1.0. It's not unlikely (in fact, it's quite likely) that we return to trunk (or the 1.9 branch) before 1.0.
I think 0.6a1 sounds reasonable, because 0.5 will be from branch. We can always bump the trunk again if it turns out that 0.7 will also be from the same gecko1.8 branch.
The original problem was that we were specifying our trunk and branch version numbers to be the same.  This screws up AUS because it has an array which maps version number to branch/trunk.  This is exacerbated by the fact that our version numbers do not follow Fx/Tb's so where we may want 1.0 to be trunk, for Fx/Tb it is branch.

At the moment, my thought is to use 0.6a1 for trunk, and leave branch at 0.4a1.  We can then bump everything forward once 0.5 ships.
One other note:
If we can decide on the version number for trunk, we can have morgamic edit the patch in bug 364628 so we don't cause them to roll AUS again just to update our version numbers.
Depends on: 364628
Blocks: 365342
No longer blocks: 365342
Depends on: 365342
The version bump is needed asap, because there are now Linux builds from both 1.8 branch and trunk with version 0.4a1. This results in confusion in the update system:

* yesterdays trunk build, from http://ftp.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/2007-01-12-03-trunk/ requests
https://aus2.mozilla.org/update/1/Sunbird/0.4a1/2007011203/Linux_x86-gcc3/en-US/nightly/update.xml
and is offered the 2007011304 trunk build.

* yesterday's branch build, from http://ftp.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/2007-01-12-10-mozilla1.8/ requests
https://aus2.mozilla.org/update/1/Sunbird/0.4a1/2007011210/Linux_x86-gcc3/en-US/nightly/update.xml
and is offered the same trunk build.

Trunk builds should continue to update ok (due to the separation of snippets in the AUS data store), but branch ones will keep being offered trunk updates.

This problem didn't show up in the Mac builds because trunk is Universal while branch is PPC only.
Oops, the previous comment would have been better on bug 365342.
Blocks: 367380
This is fixed now, by bug 367804 bringing the changes from bug 367804 and bug 365342 into production.

Bug 367380 is not fixed by this resolution, because the trunk tinderbox are currently building the SUNBIRD_0_3_0_BRANCH for the 0.3.1 maintenance release.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.