I forgot to explain how it helps imho: * a single release per component (less jira work, less release notes, less work overall for the RM), ability to use the maven release plugin * easier to consume for users (you just grab all bundles with the same version), less documentation to write about compatiblity between bundles * does not remove any osgi semantic at the package or bundle level * easier for svn layout (we can have a trunk/tags/branches per component and we'd have a nice mapping between releases / svn layout which is also git friendly)
On Tue, Feb 22, 2011 at 14:35, Guillaume Nodet <[email protected]> wrote: > 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 > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
