On 14 February 2011 07:32, Guillaume Nodet <[email protected]> wrote: > 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. >
While this is possible I think it is majorly sucky. When you have a bundle: a.b.c-.0.4.jar it isn't clear what level of bundle you have unless you crack it open and look at the manifest. I would not be in favour of this. >> >> [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. > In terms of the API I disagree, we should not push an API minor, or major, version up unless we have to within the rules of semantic versioning. When it comes to the bundle version I am prepared to be a little more flexible in my staunch view. If we aded a new blueprint namespace to our blueprint implementation, or amended an existing one this, in my view, would be a minor version update even though we don't change the API. I think this is a case by case basis though. I do not think we should just bump the minor version for no particularly good reason. >> >> Zoe >> >> >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > -- Alasdair Nottingham [email protected]
