Hi all,

After tailoring the last release I would like to share my experiences.

Ideally we can release an individual module right after some issues were
fixed against it. In some cases this is however not practical. The changes
in the core RDF modules required adaptations in most modules. Also in other
cases updating a dependencies requires changes in several modules. In many
case with the change of a module one also wants to update the enclosing
bundle-list and launcher.

So far the best approach I've found for multi-module releases is the
following:

- create a new reactor, like the one in /releases/201505/. Add the required
modules, to make sure you didn't forget anything try building this reactor
with disabled snapshot repositories and after org/apache/clerezza from the
local repository.
- create an assembly descriptor to have a source assembly (see
releases/201505/src/assembly/source-release.xml). I didn't find a way to
have the assembly include the sources of the modules that are part in the
reactor and preserve the relative paths, the work around was to have the
list of directories in the assembly descriptor too, once you have the
required modules in the reactor, copy the list to the assembly descriptor
and do the necessary search/replace.
- The maven-release-plugin shall be configured not to update dependencies
(to the next development version), so that at the end the modules in master
depend on the released versions of the other modules (as they normally
should)
- run mvn release:prepare and mvn release:deploy with -DpushChanges=false
as pushing
- use git push to push
- note that after running the release plugin your will have two source
zips, one was created following the inherited configuration and does not
provide the right relative paths, so be sure to choose the right one when
calling for a vote.

An issue is that after the push the version in master will depend on the
release modules which are not available in the maven repo till after the
release got accepted. I think this could be avoided by pushing to an
alternative branch and specifying this branch when calling release:perform,
of course after the release got promoted to maven central the changes
should be pushed to master.


Reto

Reply via email to