aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Holly Cummins <holly.k.cumm...@googlemail.com>
Subject Re: Aries blueprint release timeline?
Date Wed, 28 Mar 2012 15:27:43 GMT
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 <stephan.siano@sap.com>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
>

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