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 <[EMAIL PROTECTED]> Thursday, December 16, 2004 2:39:42 PM >>> --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
