Up to release 0.3 of Aries we released all of the modules at once, along with a set of samples which demonstrated how the Aries components could be used together.
After release 0.3 we wanted to rexamine the release process, the primary motivation for this was the observation that our current process did not use semantic versioning, and, as an OSGi project we should be demonstrating best OSGi practice.
We started with the following set of requirements for any Aries release:
| No. | Description | Met currently |
|---|---|---|
| 1 | Follows OSGi semantic versioning | No |
| 2 | Must have a buildable source distribution | Yes |
| 3 | Must have release notes | Yes |
| 4 | Must be publicly announced | Yes |
| 5 | An easy way for users to download the bundles for a given component | Yes |
| 6 | Easy tagging/branching mechanism | Yes |
| 7 | A way to provide bug fixes | Yes |
| 8 | A way to ensure that a given component doesn't have conflicting dependencies | ? |
Our ideal for a release process would involve to release by module, this is really just an evolution of the process that we already use but it would involve using semantic versioning of bundles. One might visualise the process like this:
In this case, we have a module version (independent of the version of its sub-modules) and a set of sub-modules which may each be independently versioned.
### Advantages of release by module 1. Releasing a coherent set of bundles that have been built and run together 1. Releasing a buildable set of source for all constituent bundles in one zip file 1. A more consumable unit than a set of single bundles - easier for Aries consumers. A smaller number of discrete downloads. ### Disadvantages of the release by module process 1. We would have to release a whole module at once, this would mean re-releasing bundles at the same level (and with the same content) as a previous release. This is not a major issue but we would probably not want them in the www.apache.org/dist/aries directory. 1. Developer would need to be careful to version submodules poms independently from the parent/reactor pom. Again, not a major issue but a change from the way we work at the moment. 1. The Maven release plugin will not cope with having different levels of snapshot in the same release. Therefore we would either require changes in the Maven release plugin or we would have to stop using it and maintain our own alternative, to allow us to release by module. 1. It's not all clear what the strategy for branching would be. For example, consider the following scenario: In this case a release of the blueprint module at version 1.5 contains bundles blueprint-core at version 1.0.1 and blueprint-cm at version 1.0.2.
Over a period of time, development in trunk continues and a change is made to blueprint-core which mandates an increase in the major version. Another release of blueprint (version 1.6) is made containing blueprint-cm at version 1.0i.3 and blueprint-core at version 1.1.0.
Meanwhile a customer finds a problem in blueprint module version 1.5 in the blueprint-cm module. They would like a release of the blueprint module at version 1.5.1 with blueprint-cm at 1.0.3. Unfortunately this is impossible because we have already released blueprint-cm at 1.0.3 and it works with blueprint-core 1.1.0. So, we have no way to meet the requirement
## Releasing by bundle Other OSGi projects, for example Sling and Felix, release by bundle. ### Advantages of releasing by bundle 1. Other projects already do it so there is a well understood model 1. All the existing tools work 1. OSGi semantic versioning can be used properly ### Disadvantages of releasing by bundle 1. It is more difficult for a consumer of Aries modules to understand which bundles form a logical grouping 1. There are a lot of bundles to manage independently. This has implications: