apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jus...@erenkrantz.com>
Subject Re: Backport and release policy for APR and APR-UTIL...
Date Thu, 16 Dec 2004 23:12:07 GMT
On Thu, Dec 16, 2004 at 03:50:44PM -0700, Brad Nicholes wrote:
>    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.  

Yes.

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

Or the change doesn't break binary compatibility: hence it can be delivered in
a patch release.

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

Correct.

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

I think it's a lot simpler in practice than in theory.  =)

The issue is that we might want to be able to release a 1.0.9 even after a
1.2.5 is issued (for example).  So, that means we need to keep the branches
around that mark the binary compatibility (backwards and forwards!) for that
release.

Keep in mind that a program compiled against 1.2.5 is *not*
backwards-compatible to 1.0.5.  It's only forward-compatible.

I'll point out that Subversion is using roughly this same branching strategy
and hasn't had any problems.  They've mostly adopted the compatibility rules
of APR as Subversion views itself as a library rather than an app like httpd
tends to do.  Subversion are up to 1.2.0-dev in their trunk...

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

No, because APR has *very* strong versioning rules that make it clear where
the line is.  For httpd, those lines aren't necessarily as strong.  (Although
once we hit GA, those lines become a bit clearer.)  So, I believe the APR
versioning rules - if adhered to - will keep us sane without the need for RTC.
Plus, for whatever reason, people don't apply the same level of scrutiny to
httpd that they do to APR.  -- justin

Mime
View raw message