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
