Hi Ajith!
Ajith Ranabahu wrote:
Sorry for my mistake - I should have gone through the guidelines once
again. My impression was that we always tag the trunk and branch _only
No worries. It'll be a lot easier to point to these things once they're
up on the ws.apache.org site - I just haven't been able to successfully
build the site yet. :(
if necessary_ (mostly from the tag) so that we don't go through the
pains of merging more often. But I see your point - ultimately there
will be release specific versions in the trunk and that may leave a
window for someone to get a release specific code version from the
trunk at some point (and may messup the build)
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.
While we are in this subject let me clarify some things. How would the
documentation and such stuff work in this case ? especially the
release specific docs like the release note (I need to modify some of
> the XmlSchema docs to get the version from a filter. but most release
> notes can have differences other than just the version number).
> Should this be modified in the trunk (to reflect the latest release)
> or just in the release specific 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?
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]