aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From zoe slattery <>
Subject [SUMMARY][DISCUSS] Release process
Date Sun, 13 Feb 2011 14:14:21 GMT
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 


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.

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.


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?


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