Hi Glen,
There really shouldn't be much merging that needs to happen, and since SVN isn't keeping that much actual data around, branches are pretty cheap resource-wise. Having a branch for each release makes it really easy to deal with any release-specific stuff, and to fix stuff for that release later even if the trunk has moved on in incompatible ways. The basic flow is as described, branch first, then committers are briefly (during the release cycle) responsible for making sure that any changes that they make to trunk which fix bugs targeted at the release are also merged over. But since no separate work is going on on the branch, merging should be trivial.
agreed. In simpler projects like XMLSchema the only such change would be (at least most of the time) the version number. A release process does not take days and better yet one can lock the svn during the release to avoid transitional issues so merging would be virtually non existing unless there was a serious error in the branch.
Another benefit of the branch-first approach. All the release-specific stuff like version number changes goes on the branch and not the trunk. If there are general doc changes to cover API/usage items, those go into trunk and are merged over just like code. The release-notes, which are ENTIRELY version-specific, should either not exist on the trunk at all, or should simply be a template that says "replace me with real content on each release branch". :) Seem reasonable?
Very reasonable. Seems most of the projects do maintain a set of release specific documents in the trunk but that can be easily fixed. Just to make things crystal clear the tagging would occur at the final (or intermediate) release with the branch. is it ? BTW I think we should copy these guidelines to the wiki. -- Ajith Ranabahu --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
