aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alasdair Nottingham <>
Subject Re: [SUMMARY][DISCUSS] Release process
Date Tue, 15 Feb 2011 11:45:41 GMT
On 13 February 2011 14:14, zoe slattery <> wrote:
> I believe we are ruling out the middle way (release by module) as it
> presents too many challenges, both in making existing tools work, avoiding
> releasing the same thing twice in a sub-module and just being hard to
> understand. This leaves us, as Guillaume suggested originally, with a choice
> between what we have now (a single release) and some sort of
> release-by-bundle scheme.
> Releasing by bundle, with the correct semantic versioning, still presents a
> number of issues. I suggest that the next step is that I create another
> branch and attempt to devise an optimum SVN layout and process for release
> by bundles. This would still be purely experimental but it would give us
> something concrete to compare with the current process.
> I have summarised the issues that I believe you have raised below:
> How to version a bundle?
> ===============
> There is a tool [1] but it's a prototype and will not always do what we
> need. Guillaume said "Theproblem is that there are cases where a purely
> semantic change (i.e. you change a service implementation in an incompatible
> way without changing the API) can't be find by such a tool, as it can only
> work at the API (class / method) level I think." Graham agreed and said that
> we would need a way to manually specify a version. I believe Jeremy has
> asked about the state of the tool  on the dev@ace list.
> Guillaume is also right to point out that a released version of a bundle
> doesn't have to be the same as the version in development. So, a bundle
> version 1.0.1 could be released from a development stream at 0.4.0-SNAPSHOT.
> In fact, I believe it would be necessary to use this because one cannot be
> certain of the correct release version until development has finished and
> the code can be compared with the previous release.
> [1]
> What size bundles?
> ===========
> OSGi good practice (Graham) indicates separating the API from
> implementation. This argues in favour of keeping the bundles as we have them
> now. Alasdair also supported this view.
> Consumability.
> =========
> Consumers need (at least) two things:
> 1) For each "module"  what is the set of bundles (names and versions) that I
> need to implement some functionality? Eg - if I want to implement a
> blueprint service what do I need from Aries? How can I get them without
> doing multiple manual downloads?
> 2) What is the most recent complete set of released Aries bundles that has
> been tested together with a released, documented, set of the samples? Not
> being able to run the samples is the 3rd most irritating thing when looking
> at OS projects (no build instructions, and not being able to build from
> source are the first two). It's also true that the blog sample is a good
> catch-all test, in the past it has caught problems that get by other tests.
> 3) To avoid conflicts in dependencies. Guillaume raised this as a problem -
> but I believe that Alasdair addressed it in terms of using OSGi to avoid
> conflicts. Correct me if this is still an issue.
> Branching
> ======
> I don't think there is any way to combine semantic versioning and SVN
> branching in a fool proof manner. That is, if a bundle has been released at
> version 1.0.1 and again at 1.0.2 there is no 'OSGi blessed' way to release a
> bundle that fixes a single bug in 1.0.1. This situation may of course never
> happen in Aries, but surely it is a general concern? If so, has someone
> raised it with the Alliance?

I do not agree that we need, or want to support releasing a single bug
fix to 1.0.1 that isn't in
1.0.2. I think when someone asks for a release with a bug they should
get the latest level in that
major minor stream with the additional bug fixes and we should update
the micro.

> Zoe

Alasdair Nottingham

View raw message