On Tue, Feb 22, 2011 at 14:14, zoe slattery <[email protected]> wrote: > Hi Guillaume >>> >>> 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. > > This is true but I must be missing something because I don't understand how > it helps us. > To use your example, I think we could release: > > - blueprint-core-0.4.0.jar > - blueprint-core-0.3.0.jar > > and both could have a Bundle-Version of 1.0.1 > > So, we would release exactly the same code twice (but called something > different). I thought we wanted to avoid releasing the same thing twice? > What would happen if someone accidentally installed these two bundles in the > same framework believing them to have different content? > > Am I missing the point somehow?
Yes, the consequence of not releasing per-bundle is necessarily to allow the same code to be released with two different versions. But in itself that's not really a drawback. Now if you want to install two bundles that have the same symbolic-name and version, the osgi framework will throw an error per the osgi specs. Is that really a problem ? I'm not sure it is. The first question is why would you want to have those two bundles in the same container ? I think you'd rather want to update 0.3.0 with 0.4.0 in which case it should not be a problem. I think the point is that users can easily install a component by choosing all the bundles with the same version and you know which bundles work together at a glance. If you want to go into details, you can always look at the osgi metadata. > Zoe > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
