I think you've hit the nail on the head, Stephan. It would be great to do more frequent releases of some of the Aries bundles, and one of the reasons we don't is that doing releases is too hard.
I propose the following: A. We move to 1.0 versions for all of the Aries bundles where it makes sense. This will allow us to use 'proper' semantic versioning, and I think the project is now mature enough. B. We have a policy of using the minimum version of a dependency in our poms. That is, we only depend on snapshots of other Aries bundles when we actually need unreleased function. This will produce 'correct' manifests and enable independently releasable bundles. As long as we have the goal of independently releasable bundles, we *have* to write down the minimum version of a dependency in our poms, because working out the latest snapshot of a dependency is trivial, but working out the minimum version of a dependency we can accept once we've lost that information is nearly impossible. C. In order to ensure that things also work against the current code level, rather just some older version of our dependencies, we compile and test against both the minimum version, and the latest version. A. and B. are relatively straightforward. How we achieve C isn't quite so clear, but I think a phased approach to C will allow us to get going and unblock the release logjam. Phase 1: We build twice in Jenkins, using the maven versions plugin (with an include list of org.apache.aries.*) to ensure we build both a slice of current code, and with the minimum versions. The artefacts we release are the ones with the minimum versions, since these are the ones which can be independently released and installed into a system with older versions of other bundles. Phase 2: We enable developers to also test twice, to avoid the possibility of committing regressions and breaking Jenkins. We probably need to think about this a bit more - one option is David Jencks' -Pdev profile, another is the versions plugin followed by explicit reverts, a third option is a system of tagging. Each has advantages and disadvantages, I think. Phase 3: We make testing in both modes so transparent developers don't have to do anything explicitly, and so that it also works in non-command-line environments like Eclipse ( a requirement from Dan Kulps). I don't think we know how to do phase 3 yet, but I don't think this should stop us doing phase 1. I'm happy to start working on A, B, and C in a branch. Once I've got something which builds, I can submit it for general review before I merge the branches. Once we've merged we should be able to do a release of the whole of Aries at a 1.0 level, and this should give us a nice clean slate for future releases. Holly --- Enterprise OSGi in Action - http://www.manning.com/cummins On Wed, Mar 28, 2012 at 9:18 AM, Siano, Stephan <[email protected]>wrote: > Hi, > > Is there a timeline (or at least some idea of a timeline) when the current > release issues will be resolved and when blueprint 0.4.1 will be released? > > In general I think that the module-release issue which was addressed in > various mails before this (e.g. Jean-Baptiste Onofré's mail from March > 16th) cannot be resolved unless semantic versioning is introduced. Version > range imports are already done by the maven bundle plugin, so building a > bundle with some version of the bundle (e.g. util 0.3) will result in > package imports like org.apache.aries.util.tracker;version="[0.3,1)" > already now; so as long as the semantic versioning is really maintained > (which means that the version 0.5 is compatible to 0.3) having one bundle > installed that was built with util 0.3 and one that was built with util 0.5 > is supposed to work (when util 0.5 is installed). > > Of course there is some issue with testing this stuff... This could be > resolved by having version ranges in the bundle version of the maven > dependencies (e.g. [0.3,1)) and re-running the tests of all released > versions, but that means that a bundle is always built with the newest > available version of a bundle (and the maven bundle plugin will also take > the package versions from that bundle, even if this is not necessary). > > Best regards > Stephan >
