On 28 February 2011 15:55, Guillaume Nodet <[email protected]> wrote: > On Mon, Feb 28, 2011 at 15:40, Jeremy Hughes <[email protected]> wrote: ... >> I think that's something we should release. It's an alternative to an >> uber bundle: an uber bundle says here's a bunch of bundles all in one >> bundle which we have tested to work together (with a bit of extra code >> to ensure all the activators are driven). One bundle is deployed, if >> it needs to be updated the provisioning runtime has to reprovision the >> whole thing. The distro approach says the same about the bundles >> working together, now because what's being deployed is multiple >> bundles, the provisioning runtime can update just a smaller part if >> necessary. >> >> By releasing the distro we set in stone the set of bundles w/versions >> that work together. If it's just a list on our website, then it's IMO >> less consumable and fragile (for example no vote on that set of >> bundles w/versions). > > I fully agree with you on all points. What I don't understand is that > if we have to release the distribution each time we release a bundle, > we have a per-bundle versioning scheme, but a per-component release > scheme, don't we ?
By 'component' do you mean module? e.g. proxy, blueprint, application etc. If we do the above, then it sounds like the release scheme will be to release a bundle along with a distro which contains that new bundle and the most recent levels of all the other bundles in that module - i.e. the set of bundles that work together. The distro release will get its own version number which is not related to any OSGi thing. The question is, what would the versioning scheme for the distro be. I think we could use semantic versioning rules for that too. Jeremy
