Release Strategy

[Fabian Christ <ch...@googlemail.com>]

Hi,

I am following the release process of Apache Clerezza and examined
over the weekend some other projects like Felix and Sling on how they
do releases. Here are my conclusions for a Stanbol release strategy.

My first idea of a source release was to create a ZIP of a part of the
SVN source tree and package this as a release. Therefore, I did many
experiments with the Maven apache-release profile and how to create
such a release ZIP. Apache Clerezza has the same release strategy for
its first release. Today I think this is the wrong release strategy
because:

- You need 1 person who maintains the ZIP distro and takes care that
everything is included. This is likely to fail as there are many
sources for failures in a big source tree.
- Every time you want to do a release you have to adjust the ZIP assembly
- The apache-release profile helps to generate files like the LICENSE
file. But this only works well for single artifacts (POM). This does
not help that much if you want to create a release from the top level
POM. Different artifacts need other LICENSE, NOTICE files, additional
information. This is difficult to configure from the top level.
- Projects like Felix, Sling do not create source releases by ZIPing
the source tree. They create releases for each single artifact [1].
For Stanbol this would mean we release the enhancer API, the commons
stuff, entity hub, etc. basically each on its own by following the
dependencies.

[1] http://felix.apache.org/site/downloads.cgi

I propose to do releases like this:

- Do incremental releases based on the Maven artifacts
- Release each Maven artifact on its own
- Bundle Maven artifacts to component releases where it makes sense,
e.g. release all artifacts of the entity hub at once.
- A release vote may contain several released artifacts

To start the release process I would go through the dependency tree
and see what is already releaseable. For instance, there are artifacts
that do not depend on Clerezza and therefore could already be
released. To establish the practice I would start to release some
commons stuff and then go on - step by step.

A consequence from this: If someone wants to build Stanbol on her own,
she needs to checkout from SVN. There will be no single ZIP file
containing all the sources to build the Stanbol stack in a specific
version. Basically, there will be no overall Stanbol version. There
may be launcher releases (binary releases) in the future that have a
version and that contain Stanbol components in their specific version.
If we want to have Stanbol V1, V2, V3 then we have to discuss what
this should be.

-- 
Fabian
http://twitter.com/fctwitt