Dinesh Premalal wrote: > Here is a simple diagram of what you explain in this thread > [1]. I drew this just to make sure I understand it correctly. As > a simple question, According to this branching procedure , Isn't > there a risk of not propergating improvments between major > releases? If I elaborate more on this. > > As an example, Lets think about 1.0.1 minor release and 1.1.0 > major release. We do some impovements to the code base > (1.0.0)and release 1.0.1. Isn't there a chance of not > propergating those changes to 1.1.0 ? Or 1.1.0 release means > 1.0.x improvements plus API/ABI changes.
Well, again, I'm not an expert on this, I'm just trying to explain what I know about how several other projects choose to work. I think your diagram captures the process I was describing very nicely. Yes, unless I'm mistaken, it is certainly possible to patch the 1.0.x branch and forget to patch the 1.1.x branch. However, several things work against that. First, developers on these other projects normally scrutinize everything going into a branch. (Remember that they use RTC, not CTR, for branches, so a proposal requires 3 +1 votes and no -1 vetoes before it can be committed; that level of scrutiny means that it's unlikely everyone would agree to patching 1.0.x but not 1.1.x!) A less rigorous approach, such as using CTR for branches, would allow room for more errors, certainly. The other thing that I think works against the possibility of introducing patches to 1.0.x but not 1.1.x is the issue of compatibility. 1.0.1 would be a "patch" release, I think, using APR's versioning scheme. 1.1.0 would be a minor relase; 2.0.0 would be a major one. Only in 2.0.0 can be API/ABI be totally changed, have functions removed, etc. (See http://apr.apache.org/versioning.html; I believe Axis2/C is following those guidelines as well, as per http://ws.apache.org/axis2/c/versioning.html). 1.1.0 can add functions to the API/ABI over 1.0.x, mark others deprecated (but not remove them), etc. You can add new data structures for new functions, but the signatures (the arguments) of existing functions must remain intact; foo(a) can't become f(a,b), so far as I know. It would be worth checking with a real expert on this stuff, though, especially when it comes to what's possible in terms of the ABI: I think it may be possible in some cases to add fields to the end of structs, for example, but don't quote me on that. 1.0.1 can't add functions over 1.0.0 because it must be both backwards and forwards compatible. So, that means you can't introduce anything into 1.0.1 that would break the API; it's got to go into 1.1.0. That excludes a large set of possible changes right off the bat. Thus there should be only a trickle of changes going into the older branch; that means it's much less likely someone would commit something there but forget about the newer branches. Once you branch 1.1.x, one way to think about it is that you're "maintenance mode" only for 1.0.x. You can only introduce (likely small) fixes that don't alter the API, for one thing. The number of them should also be small, since that branch is stable and is also no longer the most recent stable branch. End users should be encouraged to upgrade from 1.0.0 to 1.1.0, not 1.0.1. A good practice is to always work on trunk first, then upgrade the newest branch, and only touch the older branches if it's a serious issue: e.g., a security fix or something like that. Anything else you might well only want to put into the newest branch, to encourage people to upgrade to that branch. (If you backport too many things to older branches, people won't bother to upgrade, which makes life more difficult for you!) Does that help at all? Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
