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
