Closed Bug 639726 Opened 9 years ago Closed 9 years ago

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

Categories

(MailNews Core :: Build Config, defect)

defect
Not set

Tracking

(blocking-thunderbird5.0 needed, blocking-seamonkey2.1 needed)

RESOLVED FIXED
Thunderbird 5.0b1
Tracking Status
blocking-thunderbird5.0 --- needed
blocking-seamonkey2.1 --- needed

People

(Reporter: Callek, Assigned: standard8)

References

Details

Attachments

(2 files, 1 obsolete file)

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.
(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.
blocking-thunderbird3.1: ? → ---
blocking-thunderbird5.0: --- → needed
Flags: in-testsuite-
OS: Windows XP → All
Hardware: x86 → All
Version: unspecified → Trunk
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.
> (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.
(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.
Attached patch Add the magicSplinter Review
This adds the necessary magic. The version numbers can be set by the relevant app devs when this actually happens for their apps.
Assignee: nobody → bugzilla
Status: NEW → ASSIGNED
Attachment #519133 - Flags: review?(bugspam.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.
Attachment #519133 - Flags: review?(bugspam.Callek) → review+
Checked in: http://hg.mozilla.org/comm-central/rev/635f55c59679
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
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.
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))?
(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
(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
(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 ;-)
Target Milestone: --- → Thunderbird 3.3a4
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.
Attachment #521762 - Flags: review?(bugzilla)
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.
Attachment #521762 - Flags: review?(bugzilla) → review-
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).
Attachment #521762 - Attachment is obsolete: true
Attachment #521772 - Flags: review?(bugzilla)
Attachment #521772 - Flags: review?(bugzilla) → review+
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.
You need to log in before you can comment on or make changes to this bug.