[
https://issues.apache.org/jira/browse/COMPRESS-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16037216#comment-16037216
]
Simon Spero commented on COMPRESS-399:
--------------------------------------
I have replaced the packageinfo files with the equivalent annotated
package-info.java files.
There seems to be some confusion about what these files are for, which is
probably made worse by the choice made earlier in the work-log to _initialize_
the files with the same version number (1.14.0). I'll see if I can explain
some of the issues, using commons-lang as an example (since I happen to have
some of the details handy; I'm ignoring micro releases).
OSGI uses semantic versioning for package versions. Although it can have
multiple versions of the same bundle loaded at the same time, each bundle can
only use a single version of any given package. If a client bundle wants to
use two bundles, each of which has a different version range for a package,
and which expose their use of the package to the client, the resolver needs
to find a common version that satisfies both sets of constraints (If the
package is only used internally to the bundle, and doesn't impose constraints
on a package that is used in the api, it is less likely to cause problems).
Between release 3.0 and 3.1 of commons-lang, the only binary-compatibility
related api changes were minor level (backwards binary compatible), in two
packages.
org.apache.commons.lang3 and org.apache.commons.lang3.exception. However, _all_
package versions were bumped to 3.1.0 (matching the release number).
The effect of this would be to stop any bundles compiled against release 3.1
from using the release 3.0 bundle, _even if they didn't use the two affected
packages.
For version 3.2, all package versions were again set to 3.2.0 to match the
release.
There were minor changes to several packages: a second minor level change to
org.apache.commons.lang3, and initial minor changes to
org.apache.commons.lang3.reflect, org.apache.commons.lang3.text,
org.apache.commons.lang3.text.translate, and org.apache.commons.lang3.tuple.
There was also a *MAJOR* (non binary-backwards-compatible) change to
org.apache.commons.lang3.time. Now, instead of versions being overly
restrictive , there is hidden breaking change.
Although it is possible to automatically bump package versions whenever an api
change is detected, it is probably a better practice to detect api changes in
the verify stage, and have the person who caused the api change decide if
such a change was intended, and if so change the package version number.
This is the role of the bundle:baseline goal. In addition to detecting
changes, it also suggests alternative package versions.
> OSGI package versions are overly pessimistic, except when they're overly
> optimisic
> -----------------------------------------------------------------------------------
>
> Key: COMPRESS-399
> URL: https://issues.apache.org/jira/browse/COMPRESS-399
> Project: Commons Compress
> Issue Type: Bug
> Components: Build
> Affects Versions: 1.14
> Reporter: Simon Spero
> Priority: Minor
> Fix For: 1.15
>
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> The OSGI versions in the current distributions are not being correctly
> generated. OSGI relies on package version numbers following semantic version
> properly for correct resolution.
> Current version numbers have been generated from the maven version. This has
> lead to new minor version increases for packages that have no API changed; it
> has also concealed major (breaking) changes to several packages since 1.0.
> I have created two branches that address the issue.
> Both add the bundle:baseline goal to the verify phase of the build.
> The also both have packageinfo files added to every package, containing the
> package version. These are picked up by the bundle manifest generator, and
> are used if no explicit version is given in the "Export-Package" command.
> Both branches bump the major version number for packages with any minor
> changes to 2.0.0. This makes the bundle correct, but does not fix improper
> import declarations made by users of earlier bundles.
> One branch uses the version number from the oldest version that has no
> changes when compared to HEAD, and which has not had any breaking changes
> since 1.0.0. This will fail the build because version numbers should be
> increasing, and may cause issues if an importing bundle uses a range that
> requires an identical, but higher numbered version of the package
> The other branch uses version 1.14.0 for all packages with no major changes.
> A third alternative, which I didn't add, is to just set all packages be
> version 1.14.0, and just bump major versions when required going forward. The
> bulk of the major changes happened a good few versions back, so it's not as
> bad as it could be.
> If you have a preferred option, I can create a pull request on Github
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
