1.3 Washup, release process improvement

[Simon Laws <si...@googlemail.com>]

Some things that come to mind...

fix dependency generation so that ant scripts always match distributed jars.

automate sample testing
wrap up some of the scripts that we have been using from the release wiki
page [1] into something we can run against the release
be better at using a checklist to ensure coverage of the various
combinations that we now have to cover (not sure what this means other than
having a better release report on the wiki)
separate released modules from non released modules in the trunk so we don't
have to go through the dance of deciding what is in the release each time

What else?

Simon

[1] http://cwiki.apache.org/confluence/display/TUSCANY/Making+releases

Re: 1.3 Washup, release process improvement

[ant elder <an...@gmail.com>]

On Fri, Aug 8, 2008 at 9:35 AM, Simon Laws <si...@googlemail.com>wrote:

> Some things that come to mind...
>
> fix dependency generation so that ant scripts always match distributed
> jars.
> automate sample testing
> wrap up some of the scripts that we have been using from the release wiki
> page [1] into something we can run against the release
> be better at using a checklist to ensure coverage of the various
> combinations that we now have to cover (not sure what this means other than
> having a better release report on the wiki)
> separate released modules from non released modules in the trunk so we
> don't have to go through the dance of deciding what is in the release each
> time
>
> What else?
>
> Simon
>
> [1] http://cwiki.apache.org/confluence/display/TUSCANY/Making+releases
>


Those sound like useful things (not sure about the last point) but what I
think would help more would be more frequent releases based off the previous
release tag to get out new function as its ready.

One of the big reasons it can take a long time to do the trunk releases is
that Tuscany is so big with lots of active development. Having months
between releases there ends up being lots of changes which are hard to
manage and the longer its left between releases the harder it gets to put
together a good release. It can be hard to even work out what has been
changed and often the RM is left to sort things out as others go off doing
new work which just adds to the time it takes. Trying to fix this by doing
more frequent trunk releases is difficult as it requires all developers to
be in sync and participate and there will be inevitable delays when one bit
of function gets held up.

There is a great summary of why "release early release often" is good here:
http://radio.weblogs.com/0103807/stories/2002/12/01/understandingTheImportanceOfReleaseEarlyReleaseOften.html

   ...ant