Sorry if this reply is a bit rushed. I'm on my Android On 28 March 2012 16:27, Holly Cummins <[email protected]> wrote: > 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.
I've been thinking about this on and off for a while and you're right things are now pretty mature. Currently the conflate breaking API changes and API additions into the minor version number. I think we're ready for 'proper' semantic versioning. > > 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. I'm not sure this is completely adhered to. It's also difficult to check to see whether it's being done correctly. ... > 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. So in addition to our current build a new definition would do a mvn versions:use-latest or whatever the right one is to use the latest snapshots ... then it would do the normal mvn install etc? > 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. I think the versions plugin holds some promise ... we should experiment in a branch. > 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. Agreed :-) 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 >>
