Felix Meschberger wrote: > Yes, it is true: a bundle is *just* a deployment unit (and development > unit if you wish). Nothing more nothing less. Whether a package is part > of one bundle or another does not matter at all. As such the increased > version number of a bundle just indicates: hey there are some changes in > this bundle with respect to the previous version. > > Now, the level granularity of interaction between bundles *is* the > package: bundles don't care for other bundles; they care for packages to > wire to. And it is the package we are importing and exporting. As such > we have to assign version numbes on the correct level. Yes, right.
> <SNIP/> > If I change the API in the o.a.s.api.resource package, why would it make > sense and make lives easier, if I upgrade the minor version number of > the package o.a.s.api.request, too ? In fact, this makes life even > harder for the end user: We have to upgrade the bundling implementing > the request interface (if only to increase package import version) and > we have to deploy the new bundle. Why ? Because the resource API was > upgraded. Does not make any sense at all. This is not what OSGi is about. Yes, sure, but I think this is more theory than practice. How likely is it that the there are two separate implementations, one for the resource and one for the request package? Only in this case, having different version numbers matters. Now, I as I said, having version numbers on a per package base seems to be more correct. > So lets make life harder for the us working on the exported API ! The > harder this life, the harder we will think about changing the API ! > Consider this as sort of an additional security net against too > deliberate API changes .... > > So whenever you change something in an exported package, make sure you > also think about consequences for your downstream user's in terms of > assigning the correct version number. Ok. > > Yes, it requires more thinking. Yes, it requires more work on our side. > Yes, it might be error prone. But also, it is a problem of us coders > thus helping our users. Don't place the burden on our users. This is > IMHO the wrongest thing we could do. > > Finally: We should change a version number only if there is in fact a > change. > > Granted, it is not simple and easy, but it is definitely worth the effort. Ok, so if we would do this, we would use different versions for packages and the bundle version is then just the highest version number used for one package (at least in most cases). The only problem I still have is that in the end there is no correlation between the bundle version and the package versions. If for example a bundle has two packages A and B, we start with version 0.1 for both packages -> bundle version 0.1; then we change B to 0.2 -> bundle version 0.2 but A is still 0.1. Now we change A to 0.2 as well which would result in what bundle version? 0.2.2? Now this is no problem per se, it just makes the users life a little bit harder. Imagine you search for a bundle providing package A in version 0.2 - due to the package name/bundle symbol name correlation you choose the above bundle in version 0.2 - but that one does not contain it. So a better way would be to just increase a number for bundle release, like API R1, API R2 etc :) Again, with proper tooling all of this is no problem. But maybe we should give it a try and see how it works. Carsten -- Carsten Ziegeler [email protected]
