aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Hughes <>
Subject Re: Aries blueprint release timeline?
Date Thu, 29 Mar 2012 10:06:40 GMT
Sorry if this reply is a bit rushed. I'm on my Android

On 28 March 2012 16:27, Holly Cummins <>
> 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
> 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
> 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
> 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
> 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 -
> On Wed, Mar 28, 2012 at 9:18 AM, Siano, Stephan <
>> Hi,
>> Is there a timeline (or at least some idea of a timeline) when the
>> release issues will be resolved and when blueprint 0.4.1 will be
>> 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.
>> 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
>> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message