Hi,
Carsten Ziegeler schrieb:
> Hi,
>
> it seems that this is a complicated topic; as there has been no reply so
> far, I'll give it a try :)
Yes, it is -- to a certain extent ;-)
>
> First, I agree with most of what you wrote below :)
>
> But :) while I see that it makes sense to specify versions on a per
> package base, I'm not sure if this is worth it. If you specify the
> version per package you have the least disruptive and most compatible
> behaviour and it is no problem for OSGi (or any other tooling) to wire
> everything correctly together.
> But I fear that this is too complicated for us humans :) (at least it is
> for me...) - we have this nice notion of a module (aka bundle), which
> has a version - now although the OSGi spec does not mandate that the
> exported package inside a bundle have the same version as the bundle
> itself, it seems to be the most natural way for me. Otherwise the notion
> of a bundle becomes less important as it is just a deployment unit (more
> or less).
> So when I see an API bundle with version 2.1 I expect that the exported
> packages have version 2.1 as well - sure my expectation could be wrong,
> but that's how I would read it today (even when knowing all the problems
> you mention).
> We could end up with bundle version 2.9 while just one package inside
> has version 2.9 and others still have 2.0 - again, that's not a problem
> by itself, it seems to be more correct and OSGi has no problems with it.
> But users might have.
>
> So I'm a little bit reluctant in this case.
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.
Consider this: If we agree on the semantics for version numbers of
exported packages:
* major number change: incompatible API
* minor number change: extended but compatible API
(implementations need to be modified, users run unmodified)
* micro number change: no API change at all
(no changes needed, such updates may be JavaDoc or some
implementation fixes in exported packages)
So now we have a bundle exporting two packages with interfaces (the
Sling API comes to mind), say o.a.s.api.resource and o.a.s.api.request.
The interfaces of both packages are implemented by other bundles
importing from the API bundle.
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.
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.
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.
Regards
Felix
>
> Carsten
>
> Felix Meschberger wrote:
>> Hi all,
>>
>> <warning>lengthy mail</warning>
>>
>> In comments to SLING-1176 Ian Boston wrote:
>>
>> "The exports in bundle/api/pom.xml look like they might
>> become problematic from a support point of view, although
>> we probably cant avoid this.
>> [...]
>> [The problem is the] manual maintenance of the version numbers.
>> (not a big problem bit needs to be done)"
>>
>> I agree, that this is a problem. Let me reasonate on this a bit ;-)
>>
>> As a reference you might want to read my latest blog post at [1] and
>> also what the Eclipse guys have to say [2] (great read, btw).
>>
>> So for Sling, we have three kinds of version numbers: (1) Big Sling
>> releases, (2) Sling bundles, and (3) exported packages.
>>
>> For (1) we have already an ample solution in that we just increase the
>> number from release to release. Just remember that a "big Sling release"
>> is a convenience release of existing released Sling bundles.
>>
>> For (2) version numbers are just defined as the <version> element of the
>> bundle's POM. The only restriction here is, that we decided to use even
>> numbers for releases and odd numbers for SNAPSHOTs. Whether and when
>> which version part is increased is not codified.
>>
>> For (3) the situation is more problematic since there are a number of
>> places to set exported package version number: In a packageinfo file
>> inside the package (picked up by the Bundle plugin to set the export
>> version) or explicitly in the <Export-Package> element of the Bundle
>> plugin configuration or by reference to the bundle version number using
>> the ${pom.version} variable.
>>
>> Upto now, we mostly used the ${pom.version} notation linking the
>> exported package version to the bundle version. This works well for
>> bundles with simple exports. For more complicated bundles, specifically
>> for bundles with multiple exported packages which may evolve
>> independently, this does not work well.
>>
>> Consider for example the Sling API bundle, which exports 7 packages.
>> Each of which may evolve independently. Now the resource package is
>> enhanced causing a minor version increase. Should the version numbers of
>> the other exports also be increased ? Thus acting as if there was some
>> API change ?
>>
>> I would say, no. Particularly if some API implementation bundle is
>> restricting the import version of the API implemented. Such an
>> implementation would immediately stop working because the version has
>> been increased. But since there has been no change, the implementation
>> would still be correct.
>>
>> So, I think, we should evolve the exported package versions
>> independently from each other and possibly even independently from the
>> bundle version.
>>
>> This places more burden on the developer when deciding on the exported
>> package version - in fact this requires such a decision as compared to
>> have Maven take the decision by just setting the bundle version.
>>
>> The only problem is: Where shall this be noted ? In the POM or in the
>> packageinfo file ? If we would place the packageinfo file just beneath
>> the class source files, I would say, in the packageinfo file.
>>
>> But this would require defining the class source locations as resource
>> location in the POM (at least for packageinfo) files.
>>
>> I am not sure ....
>>
>> WDYT ?
>>
>> Regards
>> Felix
>>
>> [1] http://blog.meschberger.ch/2009/10/on-version-numbers.html
>> [2] http://wiki.eclipse.org/index.php/Version_Numbering
>>
>
>
