ws-kandula-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 Mon, 27 Sep 2010 08:12:07 GMT

I think your point of view is based on a wrong assumption about the
"extra work" caused by branching earlier in the release process.
Assume that we create the branch today and that people just continue
committing to the trunk without taking into account the existence of
the 1.6 branch. If after three weeks we decide that the trunk has all
the changes that need to go into 1.6, we can merge all these pending
changes with a single svn command. Even if in the meantime, some
individual changes have already been merged to the 1.6 branch, this is
not an issue. Subversion is smart enough to manage this, provided that
the merges have been done using a client that updates the
svn:mergeinfo. That really doesn't sound like much extra work.

Actually, the strategy you are proposing will cause more extra work
because of the issue discussed in [1]. There is at least one change
(probably it's the only one) that introduces a dependency on Axiom
1.2.10. However, this change is not critical and can wait for Axis2
1.6.1, i.e. we don't need a new Axiom release for Axis 1.6. With your
strategy, we would need to temporarily revert that change and reapply
it after the release. On the other hand, if we create a 1.6 branch
now, we simply leave that change on the trunk and only remove it from
the branch.

Finally, switching the dependencies of the trunk from snapshots to
releases also means that we loose our ability to detect issues
introduced by changes in upstream projects, i.e. continuous
integration will no longer be effective. Since you assume that it will
take quite some time to get 1.6 out, this may become an issue.



On Mon, Sep 27, 2010 at 01:22, Glen Daniels <> wrote:
> Hi Andreas,
> On 9/26/2010 5:10 PM, Andreas Veithen wrote:
>> First, these guidelines were written at a time when Subversion didn't
>> have an effective mechanism to track merges. Second, there is also a
> The guidelines were written simply to avoid extra work and therefore the
> possibility of skew.
>> 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.
> I see your point here.  How about we amend the process to say that trunk can
> be switched over to static versions of dependencies at any time, but as a
> general guideline we should be SNAPSHOT-ing at least the dependencies that we
> know are evolving with us (XmlSchema, Axiom, etc...).  Then we can just do
> the experimentation to make sure we're working with the latest releases of
> our dependencies on the trunk.  That's just considered one of the things we
> do as we get ready for a release, just like fixing particular JIRAs targeted
> at the release - but we still don't cut the branch until we've got a release
> plan in place.
> If we require our dependencies to do a new release before we can release,
> then we manage that on the trunk also.
> Thoughts?
> --Glen
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message