apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <BNICHO...@novell.com>
Subject Re: Backport and release policy for APR and APR-UTIL...
Date Thu, 16 Dec 2004 22:50:44 GMT
   So if I understand this correctly, the policy for APR is to simply
put all code changes into TRUNK and each release should bump the minor
version number and create a new branch.  The only time that there is a
patch release is if there is some critical reason for it which in this
case would cause a patch level bump but no new branch.  There is no need
for backport reviews/votes since there isn't a branch to backport to and
if or when an incompatible change needs to be committed, that is when
1.x would branch and TRUNK would become 2.x.  

>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

   I must still be missing something because this just seems really
unorganized and confusing.  If the above is true, then when 1.x finally
does branch and TRUNK becomes 2.x, we will have a 1.0.x branch, 1.1.x
branch ... 1.xxx.x at the same level as a pure 1.x branch.  Shouldn't
all 1.xxx.x branches fall under a 1.x branch?  Because once the 1.x
branch is created all subsequent 1.xxx.x branches must be created under
the 1.x branch since TRUNK would then be 2.x, true?  (Wow, even trying
to explain it is confusing).

   Also given the level of discussion about RTC vs. CTR at ApacheCon,
it seems that some that were arguing strongly for the need of RTC in
HTTPD don't seem to mind CTR in APR.  Not that I am complaining (being
one of the few that argued against the strict use of RTC) about CTR in
the APR project, but the whole thing just doesn't make sense.  Don't the
same stability arguments for RTC in the HTTPD project apply to the APR
project as well? Again, not that I am complaining, I just want to
understand.

Just trying to get this straight so that I can appropriately follow the
correct procedure.

Brad

>>> Justin Erenkrantz <justin@erenkrantz.com> Thursday, December 16,
2004 2:39:42 PM >>>
--On Wednesday, December 15, 2004 4:40 PM -0700 Brad Nicholes 
<BNICHOLES@novell.com> 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

Mime
View raw message