Eric Lemings wrote:
-----Original Message-----
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Thursday, April 24, 2008 10:23 PM
To: [email protected]
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.
Martin
