Hi, Carsten Ziegeler schrieb: > 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.
Point is that there is an API bundle whose API is implemented by more than one implementation bundle: The Sling API exports API implemented by the jcr/resource, the engine, scripting/core, servlet/resolver, and possibly more bundles. IIRC this is in fact the only such case in Sling. > >> 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 :) Well, this is the same issue as for the OSGi API libraries: These (core and compendium) are at version 4.2 while the packages "exported" are at version 1.x. > Again, with proper tooling all of this is no problem. My stance is: tooling helps -- but it should not be a prerequisite. > > But maybe we should give it a try and see how it works. Yep. Lets start with the proposed changes for SLING-1176 ;-) Regards Felix
