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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
