apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Backport and release policy for APR and APR-UTIL...
Date Thu, 16 Dec 2004 23:11:42 GMT
At 04:50 PM 12/16/2004, Brad Nicholes wrote:

>   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).

When we do a version minor or version major release, we will have

>   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

svn trunk in any project shouldn't have obstacles, it doesn't
within httpd nor in apr.  Both are CTR.

Work in branches once released in RTC in httpd.  Now if you
are anxious for another 1.0 release real soon now, feel free
to propose backports to 1.0.  But the real answer might be to
solidify the code in head, branch 1.1 and stabilize it, and
release 1.1.0 (or 2.0.0 if we've had to break the API - such
as the fixes Allen is cooking.)

Once 1.1 is released, it replaces 1.0.  Nobody will have any
trouble just dropping in 1.1 binaries in place of the old 1.0.


View raw message