| # Release process requirements |
| |
| <p>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.</p> |
| <p>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.</p> |
| |
| <p>We started with the following set of requirements for any Aries release: </p> |
| |
| <table class="confluenceTable"> |
| <tr><th class="confluenceTh"> No. </th><th class="confluenceTh"> Description </th><th class="confluenceTh"> Met currently </th></tr> |
| <tr><td class="confluenceTd"> 1 </td><td class="confluenceTd"> Follows OSGi semantic versioning</td><td class="confluenceTd"> No </td></tr> |
| <tr><td class="confluenceTd"> 2 </td><td class="confluenceTd"> Must have a buildable source distribution </td><td class="confluenceTd"> Yes </td></tr> |
| <tr><td class="confluenceTd"> 3 </td><td class="confluenceTd"> Must have release notes</td><td class="confluenceTd"> Yes </td></tr> |
| <tr><td class="confluenceTd"> 4 </td><td class="confluenceTd"> Must be publicly announced </td><td class="confluenceTd"> Yes </td></tr> |
| <tr><td class="confluenceTd"> 5 </td><td class="confluenceTd"> An easy way for users to download the bundles for a given component</td><td class="confluenceTd"> Yes </td></tr> |
| <tr><td class="confluenceTd"> 6 </td><td class="confluenceTd"> Easy tagging/branching mechanism</td><td class="confluenceTd"> Yes </td></tr> |
| <tr><td class="confluenceTd"> 7 </td><td class="confluenceTd"> A way to provide bug fixes</td><td class="confluenceTd"> Yes </td></tr> |
| <tr><td class="confluenceTd"> 8 </td><td class="confluenceTd"> A way to ensure that a given component doesn't have conflicting dependencies </td><td class="confluenceTd"> ? </td></tr> |
| </table> |
| |
| ## Release all Aries components at once. |
| |
| ### Advantages of releasing everything at once and at the same level |
| |
| 1. Conceptually very simple of consumers. For example, if as a consumer I pick up something called Blueprint version 0.4 I know that I |
| will need to get Util version 0.4 to go with it. |
| 1. A relatively simple release process, one JIRA component, one set of release notes. |
| 1. We can release a set of samples at the same version with some guarentee that the samples all work with the release. |
| |
| ### Disadvantages of releasing everything at once |
| |
| 1. Not using of OSGi semantic versioning of bundles. After every we release we bump the major versions of all bundles in trunk. |
| |
| Package versions are managed separately (correctly) and the Maven bundle plugin will ensure packages are imported in the correct range based of |
| the projects dependencies. Implementers need to use "provide:=true" to get the correct range. Package export version should be maintained |
| either using package.info or in the pom.xml. |
| |
| |
| ## Releasing by module |
| <p>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: </p> |
| |
| ![rel](release_by_module.png) |
| |
| <p>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.</p> |
| |
| ### 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: |
| ![rel](dual_component_module.png) |
| <p>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.</p> |
| <p>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.</p> |
| <p>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 </p> |
| |
| ## 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:<br/> |
| - Releasing - mvn release:prepare, and so on, needs to be run for each bundle separately. However, many bundles could be rolled up into one vote. |
| - Each bundle has to have its own JIRA component |
| - Our svn tree would need to be restructured - probably in a similar way to the Sling tree. Each bundle would have its own trunk & branches. |
| 1. There are still some issues with branching and it is still possible to get into a situation similar to that described above. |