On 13 February 2011 14:14, zoe slattery <[email protected]> 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] > 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? >
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 [email protected]
