On Sun, Feb 13, 2011 at 15: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.
That's not exactly what I meant. What i meant is that even for a release, the maven version does not have to be the same than the Bundle-Version header, so we could have a bundle blueprint-core-0.4.0 with a Bundle-Version of 1.0.1. The same way we de-correlate the package version and the bundle version, we could de-correlate the maven version and the bundle version. > > [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. Those were not really addressed with maven, but I agree this is an edge case issue that we can put aside. > > > 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? Imho we should look at that the other way around. 1.0.2 should mean that his is a bug fix release over 1.0.1, which in turns mean that any change which is not a bug should lead to a minor version bump. I don't think this is really in contradiction with the semantic versioning, it's more about what you consider "backward compatible". There is the java method signatures and classes which obviously play a role in backward compatibility, but any other kind of change can impact such a compatiblity too. > > Zoe > > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
