axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Darroch <>
Subject Re: axis2/c 1.0.x branch in svn?
Date Fri, 11 May 2007 04:26:49 GMT
Samisa Abeysinghe wrote:

> Also are we to do the branching for every minor version?

   Well, every project can make its own decisions about stuff like
this, so it's really up to the group to agree on a plan.  I know
that APR and httpd both create a new branch for any change of
major or minor version numbers, e.g.:

   Then various rules govern when you can break the API/ABI --
normally only between major releases.  IIRC Axis2/C adopted the
same versioning rules as APR (which, IMHO, is a good decision):

>>    When you want to tag a new 1.0.1 release or whatever, you just
>> copy from the 1.0.x branch to the tags location.

> So if we want to do a release form svn head, does it have to be 1.1.0 
> and not 1.0.1, even if the svn head has only patches and no API changes?

   Well, yes and no -- partly it depends on whether you've made a change
in trunk that would require a minor version bump or not, but it also
relates to the workflow for getting patches from trunk to a branch to
a tag.

   As an example -- based on how a project like httpd works -- let's say
we've just released 1.0.0 and created the 1.0.x branch.  Now a patch
goes into trunk that doesn't change the API/ABI.  That can be proposed
as a backport in the 1.0.x STATUS file, and if it gets three +1 votes
(and no -1 votes, IIRC), it can be committed to 1.0.x.

   At some point 1.0.1 is then tagged from the head of the 1.0.x branch.
You don't tag 1.0.1 from trunk, even though you could at this point.
(This becomes important later on.)

   Now suppose a patch goes into trunk that does change the API/ABI,
enough to require a minor version bump.  Nothing needs to happen
elsewhere until someone wants to release that change in a new version.
At that point you copy trunk to a new 1.1.x branch, and if you want to
make a 1.1.0 release, you tag that from the head of the new 1.1.x branch.

   Next suppose a security bug fix goes into trunk that doesn't change
the API/ABI and which you'd really like to get into both branches.
So, you propose two backports, one in each branch.  If they're accepted
in each, you can commit them in both places.  (They may have to be
different if the affected code is different in the two branches,
or the patch may be identical in both branches if the affected code
is the same.)

   Now, if you wanted to release new versions of both branches,
you'd tag 1.0.2 from the head of the 1.0.x branch, and 1.1.1 from the
head of the 1.1.x branch.

   As a note -- the only reason I suggested making the 1.0.x
branch from the 1.0.0 release is to ensure that it starts in sync
with the first 1.0.x release.  If you copy it from trunk now,
it'll be "ahead" of 1.0.0.  But that's a special case.  Normally,
as described above, you'd copy a branch from trunk, and then make a
tag from the head of the branch.

   Does that help?  Obviously these guidelines aren't written in stone
anywhere, they're just what other projects have settled on.  SVN
will let you do all kinds of crazy stuff if you want to!  :-)


GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263  E4DE C8E3 FA36 366A 375B

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

View raw message