axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dinesh Premalal <>
Subject Re: axis2/c 1.0.x branch in svn?
Date Mon, 14 May 2007 19:23:52 GMT
   Please find my comments inline.

Chris Darroch <> writes:
>    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.

I think this procedure is a good one. Because using RTC for branches 
will reduce the room for errors. Furthermore it will make sure both 
major releases and minor releases are in sync with respect to 
improvements. While review time devs can decide whether a patch should 
go into both releases (major and minor) or one.Whereas, I think we
should follow CTR for trunk development otherwise it will slowdown the
development process very much. Hope you mean it too.

>    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; I believe
> Axis2/C is following those guidelines as well, as per 


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

I believe that this mail cleared out lots of confusion from me, Thanks
Chris. We can say "sounds good" if only we can hear it :)

+1 for the branching proposal.

>    Does that help at all?

Yes, It helped a lot. :)

Dinesh Premalal
WSO2, Inc.;
GPG Key ID : A255955C
GPG Key Finger Print : C481 E5D4 C27E DC34 9257  0229 4F44 266E A255 955C

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message