axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Veithen <>
Subject Re: [Axis2] Creation of the 1.6 branch
Date Sun, 26 Sep 2010 21:10:56 GMT
First, these guidelines were written at a time when Subversion didn't
have an effective mechanism to track merges. Second, there is also a
guideline that says that the trunk should "be pointing at SNAPSHOT
versions of all dependencies. This allows for continuous integration
with our partner projects." This is indeed very important as the
recent issue with the XmlSchema release has shown. However, if we
don't create the branch now, we will only discover very late in the
process if we need releases from upstream projects.

Basically, there is an inconsistency between the following two items
in the release guidelines:

* Ideally a release branch is only around for a week or maybe two
before the release happens.
* Soon after a release branch is cut, the RM is responsible for
removing ALL dependencies on SNAPSHOT versions and replacing them with
officially released versions. This change happens only on the release

This is not realistic because it doesn't take into account the fact
that in some cases, replacing a snapshot dependency by an official
release requires a new release of the dependency. This obviously
invalidates the assumption that a release branch would only exist for
one or two weeks.


On Sun, Sep 26, 2010 at 22:39, Glen Daniels <> wrote:
> Hmm.  I guess I'm not entirely convinced that we should cut the branch yet. Our general
release guidelines [1] are to hold off branching until we're just about ready to release,
to avoid unnecessary merging.
> Why not just keep working on the trunk for now, at least until we resolve some of the
issues you point out?
> --Glen
> [1]
> "Andreas Veithen" <> wrote:
>>I'm going to create a branch for the 1.6 release (with the current
>>HEAD of the trunk as the baseline). The first goal will be to
>>determine if we need any releases from upstream projects. I'm aware
>>that there are still ongoing discussions about what should and what
>>should not go into the 1.6 release. This is not an issue because we
>>can always change the baseline, i.e. remove changes from the 1.6
>>branch or merge additional changes from the trunk.
>>In order to keep the branch manageable, I would like to propose the
>>following guidelines (which proved effective for the 1.5.2 release):
>>* Changes should not be done directly to the 1.6 branch. Instead, they
>>should always be done to the trunk first and then merged to the branch
>>if necessary. Of course, exceptions are made for release specific
>>changes, e.g. changes required to make the branch compatible with
>>releases from upstream projects.
>>* Merges should only be done using a recent version of the svn command
>>line client, or another client that updates the svn:mergeinfo
>>properties. This is important to keep track of the changes that have
>>been merged to the branch.
>>To unsubscribe, e-mail:
>>For additional commands, e-mail:
> --
> Sent from my Android phone with K-9 Mail.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message