stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: 4.3.x branch created
Date Mon, 28 Apr 2008 19:58:43 GMT
Eric Lemings wrote:
>> -----Original Message-----
>> From: Martin Sebor [] On Behalf Of Martin Sebor
>> Sent: Thursday, April 24, 2008 10:23 PM
>> To:
>> Subject: Re: 4.3.x branch created
>> Martin Sebor wrote:
>>> FYI: I've created the 4.3.x branch for your hacking pleasure. As
>>> the name implies, the branch is for changes that are backward but
>>> not necessarily forward compatible with 4.2.x. Binary or source
>>> incompatible changes should go on trunk only.
>> To clarify: forward-compatible changes should go on the 4.2.x branch
>> for 4.2.2, with both sets of changes (i.e., 4.2.2 and 4.3) ending up
>> getting merged to trunk (5.0). At least I think that's the process
>> we ended up with the last time we discussed the branching policy.
> So IIUC, changes are only checked in on the 4.2.x or 4.3.x branch
> depending on the compatibility of the change.  Forward compatible
> changes from 4.2.x are periodically merged to 4.3.x.  Changes to trunk
> should be minimal but, when necessary, only merged from one of these two
> branches.  That about right?

Yes. Which means that we all should try to get out of our habit
of committing everything to trunk first and then cherrypicking
compatible changes and merging them to branches. Instead, it's
easier to make the changes directly on the respective branches
and merge them all in the direction of the less strict branch
(or trunk).

We'll also need to set up nightly builds with 4.2.x and 4.3.0,
and with lesser frequency with trunk. My thinking is that the
most active branch (the one where most changes originate)
should be built the most often. That will probably be 4.2.x
in the near future, closely followed by 4.3 and then trunk,
depending on how often we merge. Since nightly builds can be
triggered by commits, we should either try to avoid merging
too often or we should schedule builds to take place less
frequently with the not-so-imminent release branches. Here's
one possible build schedule:

   4.2.x   nightly
   4.3.x   biweekly
   trunk   monthly

I'm thinking the latter might be the way to go. Would anyone
like argue for the former (less frequent merges with nightly
builds for changed sources across all branches and trunk)?

> Though I'm still not exactly sure what trunk is supposed to represent in
> relation to the existing release branches.

trunk is the equivalent of branches/5.0.x. I.e., it's for
incompatible changes.


View raw message