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

RESOLVED FIXED in Thunderbird 5.0b1

Status

MailNews Core
Build Config
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: Callek, Assigned: standard8)

Tracking

Trunk
Thunderbird 5.0b1
Bug Flags:
in-testsuite -

Firefox Tracking Flags

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

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

7 years ago
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.
(Assignee)

Comment 1

7 years ago
(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.
(Assignee)

Updated

7 years ago
blocking-thunderbird3.1: ? → ---
blocking-thunderbird5.0: --- → needed
Flags: in-testsuite-
OS: Windows XP → All
Hardware: x86 → All
Version: unspecified → Trunk

Comment 2

7 years ago
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.
(Reporter)

Comment 3

7 years ago
> (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.
(Assignee)

Comment 4

7 years ago
(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.
(Assignee)

Comment 5

7 years ago
Created attachment 519133 [details] [diff] [review]
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.
Assignee: nobody → bugzilla
Status: NEW → ASSIGNED
Attachment #519133 - Flags: review?(bugspam.Callek)
(Reporter)

Comment 6

7 years ago
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+
(Assignee)

Comment 7

7 years ago
Checked in: http://hg.mozilla.org/comm-central/rev/635f55c59679
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
(Assignee)

Comment 8

7 years ago
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
(Reporter)

Comment 11

7 years ago
(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
Created attachment 521762 [details] [diff] [review]
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.
Attachment #521762 - Flags: review?(bugzilla)
(Assignee)

Comment 14

7 years ago
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-
Created attachment 521772 [details] [diff] [review]
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).
Attachment #521762 - Attachment is obsolete: true
Attachment #521772 - Flags: review?(bugzilla)
(Assignee)

Updated

7 years ago
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.