--On Wednesday, December 15, 2004 4:40 PM -0700 Brad Nicholes <[EMAIL PROTECTED]> wrote:

  We have already created a 1.0.x branch.  Does this mean that we are
going to be creating a lot more short-lived branches?  I assume that

Yes.

when we go to 1.1 we will be creating a new branch and so forth with 1.2
etc.  I also don't see how we are separating incompatible patches from
compatible patches if everything is going into TRUNK and there is no
where to backport.  It seems like we should have created a 1.x branch
rather than a 1.0.x branch and backported from TRUNK to 1.x.  The
versioning rules don't change the fact that we don't have a way of
moving forward with a stable release branch vs. an unstable development

No. 1.1, 1.2 can add new features but they aren't backwards-compatible - this is why just a 1.x branch doesn't make sense: and we may want to do maintenance releases of the 1.0.x branch even after 1.1.0 is out. So, each minor version (1.0, 1.1, 1.2) gets its own branch.


branch.  Even if we were going to roll 1.1 today, where would be get it
from?  I assume TRUNK already contains patches that are meant for 2.x
and not 1.x and since backporting to the 1.0.x branch doesn't seem to
make sense, what do we do?  What am I missing?

As it stands, there are no 1.x incompatible changes in trunk. If we start that, we'd branch 1.x and bump trunk's apr_version to 2.x. -- justin

Reply via email to