You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by Chris Darroch <ch...@pearsoncmg.com> on 2007/05/10 19:32:14 UTC
axis2/c 1.0.x branch in svn?
Hi --
I was just poking around in SVN and it looks to me like we might
need to add a 1.0.x branch under webservices/axis2/branches. May I
suggest that we do something like the following to base a 1.0.x
branch off the 1.0.0 tag?
svn mkdir https://svn.apache.org/repos/asf/webservices/axis2/branches/c
svn copy https://svn.apache.org/repos/asf/webservices/axis2/tags/c/1.0.0 \
https://svn.apache.org/repos/asf/webservices/axis2/branches/c/1.0.x
The usual approach to maintaining a branch is then that anyone
who wants to backport a change from trunk to a branch should prepare
a patchset that applies cleanly against the branch code (as opposed to
the trunk code) and then propose it for a vote in a file named STATUS
or something like that in the branch. When it has enough votes,
you can commit the backport to the branch and mark it in the branch's
ChangeLog or CHANGES file, and remove it from the STATUS file.
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.
The real pain of this is that sometimes creating a patchset
that applies cleanly against the branch's code takes some doing, because
the branch's code has fallen way out of sync with the trunk code over time.
I confess I've been lazy about doing exactly this for some mod_dbd
changes in httpd trunk and just today that's come back to haunt me.
So, be forewarned, I guess, if we go this route; however, it does
certainly help track exactly what's changing and what has been changed
in a stable branch.
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: axis2/c 1.0.x branch in svn?
Posted by Chris Darroch <ch...@pearsoncmg.com>.
Dinesh Premalal wrote:
> 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.
Yes, I think trunk should definitely be CTR. I like the way
RTC for branches works, myself, but it does mean a sometimes *slow*
process of getting patches into branches and then into releases.
I was just describing what I've learned from other groups and
don't have a specific, fixed idea about about how Axis2/C should
work with respect to maintained branches.
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: axis2/c 1.0.x branch in svn?
Posted by Dinesh Premalal <xy...@gmail.com>.
Hi,
Please find my comments inline.
Chris Darroch <ch...@pearsoncmg.com> 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 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.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. :)
thanks,
Dinesh
--
Dinesh Premalal
dinesh@wso2.com
WSO2, Inc.; http://www.wso2.com/
GPG Key ID : A255955C
GPG Key Finger Print : C481 E5D4 C27E DC34 9257 0229 4F44 266E A255 955C
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: axis2/c 1.0.x branch in svn?
Posted by Chris Darroch <ch...@pearsoncmg.com>.
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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: axis2/c 1.0.x branch in svn?
Posted by Dinesh Premalal <xy...@gmail.com>.
Hi Chris,
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.
thanks,
Dinesh
1.http://people.apache.org/~dinesh/branch.jpeg
2.http://people.apache.org/~dinesh/branch.dia
--
Dinesh Premalal
dinesh@wso2.com
WSO2, Inc.; http://www.wso2.com/
GPG Key ID : A255955C
GPG Key Finger Print : C481 E5D4 C27E DC34 9257 0229 4F44 266E A255 955C
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: axis2/c 1.0.x branch in svn?
Posted by Chris Darroch <ch...@pearsoncmg.com>.
Hi --
> 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.
I should have explained that all of this relates to the key
difference between the principles of CTR and RTC. In the APR and httpd
projects, the CTR principle applies to trunk, that is, "Commit, Then Review".
So any committer can commit to trunk at any time; if it's a substantial
change or security fix, they should describe it in the CHANGES file, but
otherwise there's nothing special to do. (Obviously major revisions
should probably be discussed on the mailing list first.)
The branches, which are expected to be stable, are governed by
the RTC principle: "Review, Then Commit". Hence all the stuff about
proposing backports, getting votes, etc. For more, see:
http://www.apache.org/foundation/glossary.html#CommitThenReview
http://www.apache.org/foundation/glossary.html#ReviewThenCommit
Now, as far as I know, there's nothing that says all projects
must adopt these particular rules. For a younger project like Axis2/C,
it would make some sense to me if the project's developers and its
PMC decided to adopt CTR for the branches well, perhaps with some
further clarifications.
For example, maybe vetoes (for CTR, a veto means a rollback of
a change) can be made by any committer to any change in a branch.
If no tagged versions have been made since the change was introduced
to the branch, then there's nothing else to do, but if a tagged version
has been made, then the person performing the veto/rollback needs to be
in charge of organizing a new tagged version of the branch as soon as
possible. (This is on the theory that, if you're undoing something for
some reason, you probably want to get the reverted code out to end users
immediately.) Anyway, that's just a passing thought -- it might not
be appropriate.
I'd think it's probably worth dicussing these issues at the PMC
level, now that we've got a stable branch to maintain.
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: axis2/c 1.0.x branch in svn?
Posted by Chris Darroch <ch...@pearsoncmg.com>.
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.:
http://svn.apache.org/viewvc/apr/apr/branches/
http://svn.apache.org/viewvc/apr/apr-util/branches/
http://svn.apache.org/viewvc/httpd/httpd/branches/
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):
http://apr.apache.org/versioning.html
>> 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! :-)
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: axis2/c 1.0.x branch in svn?
Posted by Samisa Abeysinghe <sa...@wso2.com>.
Samisa Abeysinghe wrote:
> Chris Darroch wrote:
>> Hi --
>>
>> I was just poking around in SVN and it looks to me like we might
>> need to add a 1.0.x branch under webservices/axis2/branches. May I
>> suggest that we do something like the following to base a 1.0.x
>> branch off the 1.0.0 tag?
>>
>> svn mkdir https://svn.apache.org/repos/asf/webservices/axis2/branches/c
>>
>> svn copy
>> https://svn.apache.org/repos/asf/webservices/axis2/tags/c/1.0.0 \
>> https://svn.apache.org/repos/asf/webservices/axis2/branches/c/1.0.x
Done.
Thanks,
Samisa...
--
Samisa Abeysinghe : http://www.wso2.org/ (WSO2 Oxygen Tank - Web Services Developers' Portal)
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: axis2/c 1.0.x branch in svn?
Posted by Samisa Abeysinghe <sa...@wso2.com>.
Chris Darroch wrote:
> Hi --
>
> I was just poking around in SVN and it looks to me like we might
> need to add a 1.0.x branch under webservices/axis2/branches. May I
> suggest that we do something like the following to base a 1.0.x
> branch off the 1.0.0 tag?
>
> svn mkdir https://svn.apache.org/repos/asf/webservices/axis2/branches/c
>
> svn copy https://svn.apache.org/repos/asf/webservices/axis2/tags/c/1.0.0 \
> https://svn.apache.org/repos/asf/webservices/axis2/branches/c/1.0.x
>
> The usual approach to maintaining a branch is then that anyone
> who wants to backport a change from trunk to a branch should prepare
> a patchset that applies cleanly against the branch code (as opposed to
> the trunk code) and then propose it for a vote in a file named STATUS
> or something like that in the branch. When it has enough votes,
> you can commit the backport to the branch and mark it in the branch's
> ChangeLog or CHANGES file, and remove it from the STATUS file.
>
I am certanly +1 for this proposal. I will do the svn copy soon. In the
mean time, I have few questions. See inline below.
> 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?
Also are we to do the branching for every minor version?
Thanks,
Samisa...
--
Samisa Abeysinghe : http://www.wso2.org/ (WSO2 Oxygen Tank - Web Services Developers' Portal)
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org