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]
http://www.osgi.org/wiki/uploads/CommunityEvent2010/OSGi%20Community%202010%20-%20Brada.pdf
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?
Zoe
