639726 - Once again add configure/build magic for mozilla-2.0 branch, so comm-central can track a stable release and m-c

Status: RESOLVED FIXED

(MailNews Core :: Build Config, defect)

Description

[Justin Wood (:Callek)]

Ok, Mozilla-Central is nearing the point where they will branch.

SeaMonkey at least wants to release SeaMonkey2.1 based on the gecko 2.0 release. And for as long as we have comm-central for our SeaMonkey work, we need to also have comm-central track two mozilla branches again.

I vote (this time) for not having client.py change to silently migrate people to the m-c branch. and instead letting the checkouts continue to follow trunk, unless people want the branch.  We can however implement a new switch/option to make the migrate-to-stable-branch easier for local devs.

We will want this soon, but I do not know my current availability to implement this change.  We will also need some Release Engineering work [in separate bugs] to make sure we follow the right branch in the places and instances we want.

Of note for the involved parties, is that Mozilla/Firefox is moving to a time-based release cycle, planning to release once every 3 months, so if that is outside the scope of a planned release for other applications, we may not want/need a change for those in terms of buildbot/following.

Comment 1

[Mark Banner (:standard8)]

(In reply to comment #0)
> I vote (this time) for not having client.py change to silently migrate people
> to the m-c branch. and instead letting the checkouts continue to follow trunk,
> unless people want the branch.  We can however implement a new switch/option to
> make the migrate-to-stable-branch easier for local devs.

This is what we did with the 3.1 branch and we didn't get any objections. I don't think an extra switch is necessary - devs can easily just point at the 2.0 repo.

I'm not sure how long we'll be able to have both based from comm-central this time. I suspect there may be far reaching changes coming into mozilla-central soon.

> Of note for the involved parties, is that Mozilla/Firefox is moving to a
> time-based release cycle, planning to release once every 3 months, so if that
> is outside the scope of a planned release for other applications, we may not
> want/need a change for those in terms of buildbot/following.

Thunderbird team already knows about this, but this isn't a topic of a bug anyway.

Comment 2

[Robert Kaiser]

Callek, thanks for filing this, I think we should do this ASAP, we can continue to have the same version numbers in both version files until the branches actually start to diverge.

(In reply to comment #1)
> I'm not sure how long we'll be able to have both based from comm-central this
> time. I suspect there may be far reaching changes coming into mozilla-central
> soon.

Yes, esp. as the build-system branch will probably be merged soon and might require a number of changes on our side as well.

If we think we can't handle it this way, we probably should think about forking into a comm-2.0 very soon and cross-land patches on both repos.

Comment 3

[Justin Wood (:Callek)]

> (In reply to comment #1)
> > I'm not sure how long we'll be able to have both based from comm-central this
> > time. I suspect there may be far reaching changes coming into mozilla-central
> > soon.
> 
> Yes, esp. as the build-system branch will probably be merged soon and might
> require a number of changes on our side as well.
> 
> If we think we can't handle it this way, we probably should think about forking
> into a comm-2.0 very soon and cross-land patches on both repos.

Option 2 could certainly be to branch comm-central now/asap and instead close comm-central for a bit (so we can merge down from comm-2.0 without having to pick and chose).

It would save the manual work on this bug, but I would rather do that only if involved parties (TB and Suite) wish to.

If that is more desirable I'll file bugs and work to get the branches created. Otherwise I hope to get this patch done this week.

Comment 4

[Mark Banner (:standard8)]

(In reply to comment #3)
> It would save the manual work on this bug, but I would rather do that only if
> involved parties (TB and Suite) wish to.

I don't want to branch until we absolutely have to. I was mainly warning that I suspect it may be that we're forced to, we'll just have to wait and see.

Comment 5

[Mark Banner (:standard8)]

Attachment: Add the magic

This adds the necessary magic. The version numbers can be set by the relevant app devs when this actually happens for their apps.

Comment 6

[Justin Wood (:Callek)]

Comment on attachment 519133 [details] [diff] [review]
Add the magic

>diff --git a/mail/config/version-20.txt b/mail/config/version-20.txt
>new file mode 100644
>--- /dev/null
>+++ b/mail/config/version-20.txt
>@@ -0,0 +1,1 @@
>+3.3a4pre

Would have expected hg copies for the version files, but they are simple enough that it doesn't matter in the end.

Comment 7

[Mark Banner (:standard8)]

Checked in: http://hg.mozilla.org/comm-central/rev/635f55c59679

Comment 8

[Mark Banner (:standard8)]

I realised this changed the nightly branding on Thunderbird which we're not quite ready to do yet, so I checked in a follow-up:

http://hg.mozilla.org/comm-central/rev/b9daee5e01fd

I'll revert that in a separate Thunderbird push once we're ready to actually branch.

Comment 9

[Serge Gautherie (:sgautherie)]

PS: I just discovered ... bug 639972: mozilla-2.1 is already branched!

Then, do we want to extend "this bug" to support m-2.1 too (asap), fwiw (atm)?

***

Or would there be a plan to just skip m-2.1 (and "jump" to m-c (= future m-2.2))?

Comment 10

[Serge Gautherie (:sgautherie)]

(In reply to comment #8)
> http://hg.mozilla.org/comm-central/rev/b9daee5e01fd
> 
> I'll revert that in a separate Thunderbird push once we're ready to actually
> branch.

http://hg.mozilla.org/comm-central/rev/9a1f4931d533

Comment 11

[Justin Wood (:Callek)]

(In reply to comment #9)
> PS: I just discovered ... bug 639972: mozilla-2.1 is already branched!
> 
> Then, do we want to extend "this bug" to support m-2.1 too (asap), fwiw (atm)?
> 
> ***
> 
> Or would there be a plan to just skip m-2.1 (and "jump" to m-c (= future
> m-2.2))?

2.1 is just the mobile-repo for Fennec etc. almost identical to 2.0 except for a few mobile-needed patches that were deemed too risky for Firefox.

I do not wish to build on top of 2.1 in any supported sense, as long as its not a release vehicle for Firefox, as it has no (outside test suite) desktop coverage. Unless something there changes we'll be skipping this Gecko Version

Comment 12

[Serge Gautherie (:sgautherie)]

(In reply to comment #11)
> 2.1 is just the mobile-repo for Fennec etc.
> 
> Unless something there changes we'll be skipping this Gecko Version

Ah, I didn't know (yet). Anyway, thanks for the fast and explicit answer ;-)

Comment 13

[[e-mail]]

Attachment: Move version check to (somewhere) after definition of $PERL

My configuration failed to detect the branch because it couldn't run milestone.pl because it didn't know how to invoke Perl. We already retrieve the mozilla version, so I thought we might as well move the branch check there.

Comment 14

[Mark Banner (:standard8)]

Comment on attachment 521762 [details] [diff] [review]
Move version check to (somewhere) after definition of $PERL

Experience is nagging me that moving it down to there is way too far down the configure.in script. I think we're highly likely to need it for something before then.

I think I'd rather have the perl check moved up, or maybe the code to just below the perl check.

Comment 15

[[e-mail]]

Attachment: Move version check to immediately after definition of $PERL as per comm-1.9.1

Indeed, I should have compared with comm-1.9.1 which puts the branch check immediately after the Perl check (and also removes the duplicate version).

Comment 16

[[e-mail]]

Comment on attachment 521772 [details] [diff] [review]
Move version check to immediately after definition of $PERL as per comm-1.9.1

Pushed changeset 3ea6ec5aa1f5 to comm-central.