[
https://issues.apache.org/jira/browse/COMPRESS-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16034816#comment-16034816
]
Simon Spero commented on COMPRESS-399:
--------------------------------------
I ended up doing the third option, which probably needs a squashing.
There's a tool to tell you when to bump... it's a different goal (baseline) of
the plugin you'e already using.
It's already set up in all three branches, and will fail the build at the
verify stage if the version numbers are mismatched.
[For semantic versioning, major versions are needed for any breaking api
changes. Breaking apis is usually not a good thing, but it's better to make it
obvious than to hide it.
The good thing about osgi modularity is that internal changes to private
packages don't count. Also, when resolving a module, as long as there's some
set of versions of every required dependency packages that are consistent with
all package version constraints, a bundle can be resolved. So if my module
needs to use packages from modules A and B, with the former requiring a package
from Compress between 1.4 and 2, and the latter requiring one between 1.5 and
2, the system will use package version 1.5. This is fine, as long as only
non-breaking changes happened.
The trouble with OSGI is that until you understand why it does things the way
it does, it just seems ridiculously complicated, and until you learn about the
bits that are there to take care of the complexity for you (e.g. Declarative
Services), handling the dynamic of the environment is painful.
I hated it until I started trying to work with Jigsaw early last year. The
issues with jigsaw help explain a lot of the design decisions in OSGI ]
> 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)
