Closed Bug 432658 Opened 13 years ago Closed 13 years ago

Change mozilla-central product version to 3.1a1pre instead of 4.0pre

Categories

(Firefox Build System :: General, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: vlad, Assigned: reed)

References

Details

Attachments

(3 files, 2 obsolete files)

Right now mozilla-central is identifying itself as 4.0pre, breaking all sorts of things, and missetting expectations.  It should be identifying itself as 3.1a1pre (or whatever the right version number is for the initial 3.1 release).
Has there been a public discussion of this change, and the 3.1 release in general?
AUS needs to be updated as well, otherwise updates will break.

http://mxr.mozilla.org/mozilla/source/webtools/aus/xml/inc/config-dist.php#84
(In reply to comment #2)
> AUS needs to be updated as well, otherwise updates will break.
> 
> http://mxr.mozilla.org/mozilla/source/webtools/aus/xml/inc/config-dist.php#84
> 
morgamic: is this AUS change something we'd need to do before opening mozilla-central?
Ok, so what's the new version?

Do we need 3.1a1pre -> trunk, or what?
Sorry that's vague -- the mapping that Ben pointed to simply relays the product version in the URL string to the directory on disk with relevant data.  So two versions:

1. version coming from the client in the url
2. branch version which is the name of the directory created by build system

What are 1. and 2. for 3.1a1pre -- kind of confused.
(In reply to comment #4)
> Ok, so what's the new version?
> 
> Do we need 3.1a1pre -> trunk, or what?
> 

3.1a1pre
The shortest path would be to map
  '3.1*'    => 'mozilla2'
and bump the app version (the nightly builds from the mozilla-central branch push into the mozilla2 dir on AUS). 

Leaving the 4.0* mapping for a while _might_ bring anyone using 4.0pre "forward" to 3.1a1pre, depending on how AUS and the partial update generator cope with the version going backwards. I'm guessing there's not very many 4.0pre users to orphan but does anyone have a way to get actual stats ?

A better mapping would be 
  '3.1*'    => 'mozilla-central'
with an update to
  http://hg.mozilla.org/build/buildbot-configs/index.cgi/file/c030b26bbaec/mozilla2/master.cfg#l34
I think it's clearer to use the Hg branch name going forward, since what we use the branch for might change as we switch over from CVS.
Any news here?  We don't really care about bringing 4.0pre users back to 3.1a1pre, or bringing 3.0pre nightly users to 3.1a1pre, etc.  I don't have answers to morgamic's question (I'm pretty sure the answer for the first question will be "3.1a1pre", but I don't know the answer to the second).
John or Nick -- the branch dir is mozilla2 or mozilla-central?  If we just need to pick something, fine -- let's do it.  :)
Looks like mozilla2:
drwxr-xr-x  5 ffxbld firefox 4096 Apr 17 07:39 mozilla2
Attached patch v1, mapping 3.1* -> mozilla2 (obsolete) — Splinter Review
This would map 3.1* URLs onto the mozilla2 branch directory.

We haven't discussed what will happen further down the road with 3.0*:
* should we move 3.0* out of /trunk and into /3.0 then point 3.1* and 4.0* at /trunk? 
* is it hard to do? should we leave things how they are and use mozilla2 instead?
* should we fix it sooner than later
Attachment #320766 - Flags: review?
Attachment #320766 - Flags: review? → review?(nrthomas)
Comment on attachment 320766 [details] [diff] [review]
v1, mapping 3.1* -> mozilla2

>+        '3.1*'    => 'mozilla2'

Lets map 3.1* to 'mozilla-central' (since the builds are from the mozilla-central, and mozilla2 != mozilla-central any more), r+ with that.
Attachment #320766 - Flags: review?(nrthomas) → review+
Attached patch Change version number - v1 (obsolete) — Splinter Review
Assignee: nobody → reed
Status: NEW → ASSIGNED
Attachment #320787 - Flags: review?(nrthomas)
Comment on attachment 320787 [details] [diff] [review]
Change version number - v1

Looks fine but might be incomplete. Vlad/schrep, do you want the Gecko revision to stay as 2.0a1pre ?
(In reply to comment #14)
> (From update of attachment 320787 [details] [diff] [review])
> Looks fine but might be incomplete. Vlad/schrep, do you want the Gecko revision
> to stay as 2.0a1pre ?

Ah, good point. If this is for Firefox 3.1, that's probably Gecko 1.9.1, right?
Use Gecko version 1.9.1a1pre.
Comment on attachment 320787 [details] [diff] [review]
Change version number - v1

New patch pls
Attachment #320787 - Attachment is obsolete: true
Attachment #320787 - Flags: review?(nrthomas)
Attachment #320790 - Flags: review?(nrthomas) → review+
Not that we have many/any users, but the 4.0a1pre builds were brought "forward" to 3.1a1pre.
We'll need to land this at the same time as attachment 320766 [details] [diff] [review] so snippets get pushed to the right place.
Attachment #320916 - Flags: review?(nrthomas)
Comment on attachment 320916 [details] [diff] [review]
[checked in] changes to buildbot config for s/mozilla2/mozilla-central on aus2

r+

> We'll need to land this at the same time as attachment 320766 [details] [diff] [review]
> [details] so snippets get pushed to the right place.

We could move the mozilla2 dir to mozilla-central and put in a symlink to dodge this.
Attachment #320916 - Flags: review?(nrthomas) → review+
Just to make sure this is what cf is asking for...
Attachment #320766 - Attachment is obsolete: true
Attachment #320931 - Flags: review?
Attachment #320931 - Flags: review? → review?(nrthomas)
Comment on attachment 320931 [details] [diff] [review]
aus config update for mozilla-central

WFM
Attachment #320931 - Flags: review?(nrthomas) → review+
(In reply to comment #21)
> We could move the mozilla2 dir to mozilla-central and put in a symlink to dodge
> this.

Just did this. In /opt/aus2/build/0/Firefox/, mozilla2 moved to mozilla-central, and now a symlink points to it from mozilla2.
On seconds thoughts, twas a silly plan. Undone.
Comment on attachment 320790 [details] [diff] [review]
[checked in] Change version number - v2

Reed landed this in changeset 15118	e4715d4efc28
Attachment #320790 - Attachment description: Change version number - v2 → [checked in] Change version number - v2
What's blocking this bug from being marked fixed?
Nothin, just had to coordinate when we were going to make the switch.  Working on it now.
Depends on: 433771
Why was bug 433771 filed as IT-only?
Pushed to prod - so the aus2 server-side change it done.

@reed - because "please update aus2" is super sekrit.
nthomas - think this is done, resolving.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Comment on attachment 320916 [details] [diff] [review]
[checked in] changes to buildbot config for s/mozilla2/mozilla-central on aus2

Forgot to land this one.

Landed in changeset:   62:e177859d6343
Attachment #320916 - Attachment description: changes to buildbot config for s/mozilla2/mozilla-central on aus2 → [checked in] changes to buildbot config for s/mozilla2/mozilla-central on aus2
Thx Ben. :)
Bumping the DOM inspector extension compatibility needs to become part of the standard version bump routine as well (see bug 433935).
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.