Re: OSGi Version at Package Level

[Bernd Eckenfels]

Hello,

Just a pointer, those constraints come in handy when you plan to have OSGi do. 
the final resolving of actual deployed systems as well. It might not be your 
cup of coffee but I recommend the modularity talk of Peter Kriens 2016 at the 
modconf in Darmstadt: https://youtu.be/VwD0pYNOvFQ to get a radically different 
view.

(But Imagree with others that for most commons projects (especially tools 
libraries) there is not much benefit for having package versions different from 
bundle versions. Especially not since there is no overall OSGi theme going on.)

Gruss
Bernd
--
http://bernd.eckenfels.net

From: Bertrand Delacretaz <bdelacre...@apache.org>
Sent: Wednesday, June 21, 2017 9:03:28 AM
To: Commons Developers List
Subject: Re: OSGi Version at Package Level

On Wed, Jun 21, 2017 at 12:08 AM, Simon Spero <sesunc...@gmail.com> wrote:
> Bundles can specify all sorts of Requirements, including implementations,
> and bugfix version ranges...It can be a
> little too expressive :-)...

Yes, in the OSGi projects where I'm involved we avoid these things as
they create more coupling than we like.

When working in that way, getting the right implementations is a
deployment concern, and the OSGi framework "just" makes sure
everything that's deployed is compatible at the API level.

-Bertrand

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: OSGi Version at Package Level

[Bertrand Delacretaz]

On Wed, Jun 21, 2017 at 12:08 AM, Simon Spero  wrote:
> Bundles can specify all sorts of Requirements, including implementations,
> and bugfix version ranges...It can be a
> little too expressive :-)...

Yes, in the OSGi projects where I'm involved we avoid these things as
they create more coupling than we like.

When working in that way, getting the right implementations is a
deployment concern, and the OSGi framework "just" makes sure
everything that's deployed is compatible at the API level.

-Bertrand

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: OSGi Version at Package Level

[Gary Gregory]

On Jun 20, 2017 3:08 PM, "Simon Spero"  wrote:

On Tue, Jun 20, 2017 at 10:18 AM, Stefan Bodewig  wrote:

>
> Interesting. This means OSGi only provides a way for consumers to say
> which version of an API they want, but not which implementation. This
means
> as a consumer you can't say "I want version 1.19 of Compress because I
know
> it contains an important fix". This feels more limited in expressiveness
> than I had expected.
>

Bundles can specify all sorts of Requirements, including implementations,
and bugfix version ranges  (by default, the bugfix component is not
specified in the lower bound, but that is just a default).   It can be a
little too expressive :-)

If a new version becomes available, it can often be swapped in dynamically
(e.g. when using Declarative Services (née Felix SCR)  with Greedy dynamic
reference, an inject  service will be replaced whenever a newer version is
available).

For more on updating and refreshing bundles see:
https://stackoverflow.com/questions/4330927/how-does-osgi-bundle-update-work


I do feel that it ought to be possible to have  more aggressive updates for
critical (security) release, though  that's a little orthogonal to the
version range issue.


One day, in a galaxy far far away, we will just be able to push a button to
release...

Gary

Re: OSGi Version at Package Level

[Simon Spero]

On Tue, Jun 20, 2017 at 10:18 AM, Stefan Bodewig  wrote:

>
> Interesting. This means OSGi only provides a way for consumers to say
> which version of an API they want, but not which implementation. This means
> as a consumer you can't say "I want version 1.19 of Compress because I know
> it contains an important fix". This feels more limited in expressiveness
> than I had expected.
>

Bundles can specify all sorts of Requirements, including implementations,
and bugfix version ranges  (by default, the bugfix component is not
specified in the lower bound, but that is just a default).   It can be a
little too expressive :-)

If a new version becomes available, it can often be swapped in dynamically
(e.g. when using Declarative Services (née Felix SCR)  with Greedy dynamic
reference, an inject  service will be replaced whenever a newer version is
available).

For more on updating and refreshing bundles see:
https://stackoverflow.com/questions/4330927/how-does-osgi-bundle-update-work


I do feel that it ought to be possible to have  more aggressive updates for
critical (security) release, though  that's a little orthogonal to the
version range issue.

Re: OSGi Version at Package Level

[Stefan Bodewig]

On 2017-06-20, Bertrand Delacretaz wrote:

> On Thu, Jun 15, 2017 at 6:53 PM, Stefan Bodewig  wrote:
>> ...We use the default configuration of the bundle plugin, only marking some
>> imports as optional. So we are exporting all our packages...

> Ok. In the OSGi world it's only APIs and utility classes that should
> be exported, implementations should be hidden.

> But this requires separating these things (API, public utilities,
> implementation) in their own packages - if you don't do that, using
> OSGi semantic versioning might not help much and the whole thing might
> be moot.

It may be more difficult than that. Some format specific packages are
actually mixtures of API and implementation as we provide extensions
only supported for a specific format. Things like which compression
level to use for gzip or the dialect to use when tar encounters file
names longer thann 100 characters ...

> And reorganizing your packages might cause too much pain compared to
> the benefits, although it's good in the long term. So maybe something
> for a major release.

If we ever get enough momentum for this, yes :-)

> The format specific packages should be only implementation, correct?
> With only their APIs being exported.

Not in our current world, no.

>> ... What bad happens if the published version of a package changes even if
>> there is no change at all - this is what happens for some packages if we
>> keep on doing what we have done all the time

> As above - this will require some OSGi users to upgrade or recompile
> other bundles that depends on yours, although technically that
> wouldn't be needed.

Understood, thanks.

>> ...What I really wanted to say is if the bugfix means the exported package
>> version now is "1.17.1" and the bundle version is "1.19" won't we
>> confuse the hell out of our users if we tell them they need version
>> 1.17.1 of the package that's contained inside of Compress 1.19 - as
>> opposed to telling them "upgrade to Compress 1.19"?...

> If the exported package versions haven't changed (because the bugfix
> code is implementation only so not exported) , in OSGi you can use
> either the old or the new version of the bundle, without any other
> changes to your system as OSGi won't see the change. Users will have
> to be informed to upgrade to 1.19 to get the bugfix, and based on no
> exported package versions having changed they will know they don't
> need any other changes in their system.

Interesting. This means OSGi only provides a way for consumers to say
which version of an API they want, but not which implementation. This
means as a consumer you can't say "I want version 1.19 of Compress
because I know it contains an important fix". This feels more limited in
expressiveness than I had expected.

>> ...I'm also afraid we'll have to grep through git logs to figure out which
>> version of Compress a bug is reported against if the reporter talks
>> about the version of an exported package rather than the version of the
>> bundle

> They shouldn't, tracking should always happen against the version of
> the artifact that you release.

Phew, this is good. :-)

> I think the key is cleanly separating the code so that Java packages
> do not mix APIs, public utilities and bundle-private code.

> If that's done, the rest follows naturally.

> If that's not done, having independent version numbers for each
> package might cause more pain that benefits.

Thank you very much.

> HTH, and nice "talking" to you Stefan after all this time!

Indeed!

Cheers

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: OSGi Version at Package Level

[Bertrand Delacretaz]

Hi Stefan,

On Thu, Jun 15, 2017 at 6:53 PM, Stefan Bodewig  wrote:
> ...We use the default configuration of the bundle plugin, only marking some
> imports as optional. So we are exporting all our packages...

Ok. In the OSGi world it's only APIs and utility classes that should
be exported, implementations should be hidden.

But this requires separating these things (API, public utilities,
implementation) in their own packages - if you don't do that, using
OSGi semantic versioning might not help much and the whole thing might
be moot.

And reorganizing your packages might cause too much pain compared to
the benefits, although it's good in the long term. So maybe something
for a major release.

> ...If the API of a package changes with a new release we are on the safe
> side with the current approach...

Yes. You might cause unnecessary incompatibilities with client OSGi
bundles that specify a restricted import versions range, that's
inconvenient but not dramatic.

>
> ...What is the expectation if only the implementation of a package changes?...

That should be invisible from the OSGi side of things. You will
mention in your release notes that users need to upgrade to the new
*bundle version* to get the new implementation, but the versions of
the OSGi exported packages wouldn't change.

Again this is moot if everything's exported or if packages mix things up.

> ...What is the expectation for the format specific packages if the version
> of the utils package they internally depend on changes? Do the format
> specific packages need a version update as well? Does the bundle plugin
> detect this?...

The format specific packages should be only implementation, correct?
With only their APIs being exported.

>
>... What bad happens if the published version of a package changes even if
> there is no change at all - this is what happens for some packages if we
> keep on doing what we have done all the time

As above - this will require some OSGi users to upgrade or recompile
other bundles that depends on yours, although technically that
wouldn't be needed.

> ...What I really wanted to say is if the bugfix means the exported package
> version now is "1.17.1" and the bundle version is "1.19" won't we
> confuse the hell out of our users if we tell them they need version
> 1.17.1 of the package that's contained inside of Compress 1.19 - as
> opposed to telling them "upgrade to Compress 1.19"?...

If the exported package versions haven't changed (because the bugfix
code is implementation only so not exported) , in OSGi you can use
either the old or the new version of the bundle, without any other
changes to your system as OSGi won't see the change. Users will have
to be informed to upgrade to 1.19 to get the bugfix, and based on no
exported package versions having changed they will know they don't
need any other changes in their system.

> ...I'm also afraid we'll have to grep through git logs to figure out which
> version of Compress a bug is reported against if the reporter talks
> about the version of an exported package rather than the version of the
> bundle

They shouldn't, tracking should always happen against the version of
the artifact that you release. Exported package versions then
naturally derive from whatever changes are made, and provide API-level
compatibility guarantees that are very useful in large systems.

>... Maybe I'm making a bigger problem of this than it really is...

I think the key is cleanly separating the code so that Java packages
do not mix APIs, public utilities and bundle-private code.

If that's done, the rest follows naturally.

If that's not done, having independent version numbers for each
package might cause more pain that benefits.

HTH, and nice "talking" to you Stefan after all this time!
-Bertrand

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: OSGi Version at Package Level

[Stefan Bodewig]

On 2017-06-12, Bertrand Delacretaz wrote:

> I'll do my best to answer from my heavy OSGi user's point of view -
> but as mentioned I know little about the specifics of Compress.

Thanks, Bertrand. You don't really need to know specifics about
Compress. It contains some packages that provide the generic API for
compression and archiving and they don't change that often. Then there
is a utils package that changes more frequently. And we've got a bunch
of format specific packages, many of which don't change at all between
versions, some of them only change the implementation (fixing bugs) and
some may add new methods or classes to add format specific features.

We use the default configuration of the bundle plugin, only marking some
imports as optional. So we are exporting all our packages.

To be honest I still feel I must be missing something.

So far all packages have the same version as the library itself,
i.e. they change the minor version with each release, even if there is
no change at all.

I do understand why signaling a minor change when there really is a
major change is a problem. But this is unrelated to the OSGi issue, so
I'd like to leave this out.

If the API of a package changes with a new release we are on the safe
side with the current approach.

What is the expectation if only the implementation of a package changes?
If we need to update the version of the package as well, them I'm afraid
no tools is going to catch this.

What is the expectation for the format specific packages if the version
of the utils package they internally depend on changes? Do the format
specific packages need a version update as well? Does the bundle plugin
detect this?

What bad happens if the published version of a package changes even if
there is no change at all - this is what happens for some packages if we
keep on doing what we have done all the time.

> On Mon, Jun 12, 2017 at 4:39 PM, Stefan Bodewig  wrote:

>> ...What if we change the implementation in "util", not in "ar", what
>> is going to happen to the version in "ar"? What will the bundle
>> plugin tell us?..

> if util is exported and changes require a version number increase then
> you do that.

> And if ar has not changed its version number stays the same.

This is what I've rephrased above. "ar" depends on "util" internally,
but that's (currently?) not visible looking at the list of exported
packages.

>> ...How would we tell our users to upgrade to version 1.19 in order to use a
>> bug fix that has been applied if this is the version of the library as a
>> whole and not the version of a package?...

> If an non-exported implementation package includes changes then you
> can tell your users to upgrade that bundle to include those fixes but
> at the OSGi level those changes are invisible as the OSGi framework
> only sees exported packages.

> That's an implementation upgrade then, but if exported packages have
> not changed you can guarantee that the system will startup without
> requiring any other upgrades, that's the beauty of OSGi.

> And if the version of an exported package changes, it will cascade
> into the whole system and force you to upgrade bundles that depend on
> it (based on their importing version range), which guarantees that if
> your system starts it has all the right versions.

What I really wanted to say is if the bugfix means the exported package
version now is "1.17.1" and the bundle version is "1.19" won't we
confuse the hell out of our users if we tell them they need version
1.17.1 of the package that's contained inside of Compress 1.19 - as
opposed to telling them "upgrade to Compress 1.19"?

I'm also afraid we'll have to grep through git logs to figure out which
version of Compress a bug is reported against if the reporter talks
about the version of an exported package rather than the version of the
bundle.

Maybe I'm making a bigger problem of this than it really is.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: OSGI Version at Package Level : some more details about the COMPRESS-399 pull request

[Simon Spero]

On Jun 13, 2017 1:48 PM, "Gary Gregory"  wrote:

I think that the best way to see how this works is to provide a patch...
then we can see how it goes.


Gary-
  Can you clarify a few things:

What would you like to see patches for - the commons parent / related mojo
one or more  commons projects, the Felix maven-bundle-plugin, or some
combination thereof?

The changes which I submitted as a pull-request for COMPRESS-399¹ (as
amended) are on
commons-compress only. https://github.com/apache/commons-compress/pull/26

The net changes:

1. Update the version of the maven-bundle-plugin used.
2. Add the bundle:baseline goal to the verify phase.
3. Add a "provided" scope maven dependency on org.osgi:org.osgi.annotation:
for the  @Version annotation.
4. Override the parent bundle:manifest configuration, with no version in
the export-package (this would override any other source of version info).
5. Add initial package-info.java files to each non-empty package,
initialized to the previously released version.
6. Change the travis.yml configuration to execute mvn verify as the build
task.
7. Add  bundle:baseline-report goal to the site phase.

An example of additional work after  a subsequent api change is
https://github.com/apache/commons-compress/pull/27/commits/82405c13bd2688817108d3f2854387b3417a764d

Some of these changes can be lifted to the parent; the initial setup of
package-info.java @Version annotations requires some code.

Simon

¹ OK, I made the changes, created the issue, then submitted the
pull-request.


On Mon, Jun 12, 2017 at 10:18 AM, Simon Spero  wrote:

> On Mon, Jun 12, 2017 at 10:53 AM, Matt Sicker  wrote:
>
> > I'd love to have a semantic versioning plugin like that which can
suggest
> > what the version number is for the entire project. Elm (programming
> > language) has a tool like that, and it works rather well in practice
> (even
> > though there are some popular libraries that are at version 5.0.0
already
> > because of it).
>
>
> The bundle:baseline goal does this (it's at the start of the report).
> Having  frequent major version bumps is a good thing if they are necessary
> and the libraries are small (definitely better than having breaking
changes
> without the bump).
> It's not as good as having *correct* semantic-version numbers of 1.4.0 :-)
>

Re: OSGI Version at Package Level : some more details about the COMPRESS-399 pull request

[Gary Gregory]

I think that the best way to see how this works is to provide a patch...
then we can see how it goes.

Gary

On Mon, Jun 12, 2017 at 10:18 AM, Simon Spero  wrote:

> On Mon, Jun 12, 2017 at 10:53 AM, Matt Sicker  wrote:
>
> > I'd love to have a semantic versioning plugin like that which can suggest
> > what the version number is for the entire project. Elm (programming
> > language) has a tool like that, and it works rather well in practice
> (even
> > though there are some popular libraries that are at version 5.0.0 already
> > because of it).
>
>
> The bundle:baseline goal does this (it's at the start of the report).
> Having  frequent major version bumps is a good thing if they are necessary
> and the libraries are small (definitely better than having breaking changes
> without the bump).
> It's not as good as having *correct* semantic-version numbers of 1.4.0 :-)
>

Re: OSGI Version at Package Level : some more details about the COMPRESS-399 pull request

[Simon Spero]

On Mon, Jun 12, 2017 at 10:53 AM, Matt Sicker  wrote:

> I'd love to have a semantic versioning plugin like that which can suggest
> what the version number is for the entire project. Elm (programming
> language) has a tool like that, and it works rather well in practice (even
> though there are some popular libraries that are at version 5.0.0 already
> because of it).


The bundle:baseline goal does this (it's at the start of the report).
Having  frequent major version bumps is a good thing if they are necessary
and the libraries are small (definitely better than having breaking changes
without the bump).
It's not as good as having *correct* semantic-version numbers of 1.4.0 :-)

Re: OSGI Version at Package Level : some more details about the COMPRESS-399 pull request

[Simon Spero]

On Sun, Jun 11, 2017 at 7:37 PM, Gary Gregory 
wrote:

> Is one upshot of this is that we should base the version number based on
> this OSGi report tool?
>

There are a few choices so the SEF upshot selector

should
be set to Fun :-)

One group of choices revolve around the term "version number".   There are
a few different version numbers involved here.

   1. The Maven version number  (i.e. ${project.version} )
   2. The OSGI bundle version (i.e. the one in the  "Bundle-Version"
   manifest header).
   3. The package version for each exported package (e.g. the value of
   version in the manifest header below)
  - Export-Package: org.apache.common.weasels;version="1.1.0"

Another group of choices revolve around interpretations of the term "base".

   1. automatically applying all suggested version numbers, without further
   review (e.g. for maven, writing  goals for the packaging phases).
   2. executing the baseline goal during the verify stage, possibly failing
   the build if the versions contain errors (or warnings), possibly only
   reporting.

Another level  of choice  is whether to have  different policies for
different levels of change.

   -  For example, if the maven version is taken as a given, code could be
   written to restrict changes to the level implied by  the maven version
   change. Thus, micro releases would be failed if any API changes, minor
   versions would be failed if no API changes, or any  Major changes, were
   found.

Some specific decisions:

   1. Setting the maven-bump match the maximum API change.
  - Advantages: This gives appropriate behavior when maven version
  ranges are used (e.g. [1.1,2)).
  - Disadvantages: If the artifact contains a lot of unrelated
  functionality, this may unnecessarily affect dependents that
don't need to
  change. This is especially problematic if it's a major-level change.
   2. Requiring *all* package version numbers to match.
  - This either requires (1), or the addition of a new, manually set
  property
  - Advantages: Require-Bundle imports with ranges will work (however,
  these are not considered good practice)
  - Disadvantages: Packages with changes at a lower level than the
  maximum will nevertheless be treated as if they had the higher level of
  changes.
 - This can require redundant  versions of identical classes to be
 loaded (if the imported packages are not used in any exported packages)
 - This can cause a system to ignore an updated artifact containing
 fixes to packages it uses, solely because of changes to
package it does not
 use.
 - In the worst case, cause systems that would otherwise have been
 resolvable to fail (e.g if a bundle wants to import two
bundles that would
 otherwise have had compatible  ranges for a used package to
no longer have
 a compatible range).
  3. Having per-package versions:
  - This requires (e.g.) incrementing the version number in a
  package-info.java @Version annotation for the first change of a
given level
  for each release.
  - Advantages:
 - most precise package versions (obviously :-).
 - Avoids disadvantages in (2)
 - Lays groundwork for use of other package annotations
- e.g.:  @Export annotation to indicate package is for export,
with other packages considered private (could also be used
for jig-slaw)
 - Disadvantages:
 - Requires updating one or more version number  per release,
 either manually or automatically
 - If NOT (1), OSGI systems that make use of pax mvn / aether URLs
  (e.g. Apache Kafka ) may not work optimally (if a repository index is
 used, this is not a problem)
  4. Automatically incrementing per-package versions:
  - Advantages:
 - Does not require developer to edit package-info.java @Version
 annotation.
  - Disadvantages:
 - Does not require developer to edit package-info.java @Version
 annotation.  "*Wait - that's not backwards compatible*?"
 - Requires some Mojo (most suitable place would be in Apache Felix
 maven-bundle-plugin).
  5. Automatically initializing per-package versions:
  - Advantages:
 - Avoids having to manually create or edit a large number of
 packages. Allows a uniform policy to be set.
  - Disadvantages:
 - Requires a small amount of code (could be new goal, could be
 groovy or bash/perl script).

A big part of the decision comes down to how to handle breaking changes.
If there is a policy to reduce unintended API changes, then manually
bumping package versions if the API change is required is probably best.  A
failing  bundle:baseline can be thought of like a failing unit  

Re: OSGi Version at Package Level

[Bertrand Delacretaz]

Hi Stefan,

I'll do my best to answer from my heavy OSGi user's point of view -
but as mentioned I know little about the specifics of Compress.

On Mon, Jun 12, 2017 at 4:39 PM, Stefan Bodewig  wrote:
> ...Say we started versioning packages with 1.15 and all untouched APIs stay
> at 1.14. We update package versions whenever there is an API change. We
> go ahead and fix a problem with an implementation detail in - say - "ar"
> in 1.19 but there is no API change. Would we modify the package version?...

No, in the OSGi world the Java package versions are completely
independent of the version of the bundle that provides them.

You can actually have several bundles providing the same package, and
the OSGi framework will do the right thing and wire the most recent
version only, unless dependencies specify something different. I
digress and that's kind of an edge case but that helps explain the
concept I think: each exported package (others ones are invisible in
an OSGi system outside of their own bundle) has its own version cycle,
independent from anything else.

So in practical terms you define the version number of the bundle as
usual, driven by your perception of how much it changes, and it's the
package version numbers that are actually important in an OSGi system.

>
> ...What if we change the implementation in "util", not in "ar", what is
> going to happen to the version in "ar"? What will the bundle plugin tell
> us?..

if util is exported and changes require a version number increase then
you do that.

And if ar has not changed its version number stays the same.

And if a package is not exported it doesn't have an OSGi version
number, its changes only affect the implementation but not the wiring
with its clients.

>
> ...Would this mean we'd need to start using bugfix version numbers for
> packages where the implementaion changes but the API doesn't? I.e. "ar"
> in Compress 1.19 would have version 1.14 (no API changes) or 1.14.5
> (five implementation changes since 1.14)?...

Yes that's totally possible as the package has its own version numbering cycle.

>
> ...How would we tell our users to upgrade to version 1.19 in order to use a
> bug fix that has been applied if this is the version of the library as a
> whole and not the version of a package?...

If an non-exported implementation package includes changes then you
can tell your users to upgrade that bundle to include those fixes but
at the OSGi level those changes are invisible as the OSGi framework
only sees exported packages.

That's an implementation upgrade then, but if exported packages have
not changed you can guarantee that the system will startup without
requiring any other upgrades, that's the beauty of OSGi.

And if the version of an exported package changes, it will cascade
into the whole system and force you to upgrade bundles that depend on
it (based on their importing version range), which guarantees that if
your system starts it has all the right versions.

HTH,
-Bertrand

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: OSGI Version at Package Level : some more details about the COMPRESS-399 pull request

[Matt Sicker]

I'd love to have a semantic versioning plugin like that which can suggest
what the version number is for the entire project. Elm (programming
language) has a tool like that, and it works rather well in practice (even
though there are some popular libraries that are at version 5.0.0 already
because of it).

On 11 June 2017 at 18:37, Gary Gregory  wrote:

> Is one upshot of this is that we should base the version number based on
> this OSGi report tool?
>
> Gary
>
> On Jun 11, 2017 1:58 PM, "Simon Spero"  wrote:
>
> > On Sun, Jun 11, 2017 at 3:16 PM, Gary Gregory 
> > wrote:
> >
> > > My POV is that I only see a possible use cases for this in multi-module
> > > components where one module defines an API and others different
> > > implementation. Our release process is enough of a pain. Asking
> everyone
> > > to consider if a change warrants a package version change is a pain. I
> > still
> > > do not see what practical and concrete problem this would solve for a
> > > single module component. Granted COMPRESSA defines an API and
> > > implementations all is one jar. But we work for 100% BC within a minor
> > > release, so no problem there right? For BC breaks, we use a new version
> > and
> > > new package name, so no problem either, right?
> > >
> > > Can you show us a real problem that this would have solved? If not,
> write
> > > up a realistic imaginary problem?
> > >
> >
> > See: e.g http://www.sciencedirect.com/science/article/pii/
> > S1571066111000399
> >
> > Note that the specific versions of *org.apache.commons.fileupload *are
> not
> > completely on point, since as far as I know the first version of
> > commons-fileupload to include bundle headers was 1.2.1
> >
> > However, we don't have to go much further to find more examples in that
> > series.
> > The bundles org.apache.commons.fileupload , version 1.2.*1*, and
> >  org.apache.commons.fileupload, version 1.2.*2*  use the  same  version
> > numbers for all packages, are two *micro* (aka bug-fix) version numbers
> > within the same micro version.  Under  semantic versioning rules, micro
> > versions must not have any API changes.
> >
> > However, between those 1.2.1 and 1.2.2, there are *minor* level changes
> to
> > two of the five packages (the other three remain unchanged.
> > Moving from version 1.2.2 to version 1.3.0,  there are *major* breaking
> > binary changes to four packages (meaning they should have version 2.0.0).
> > From version 1.3.0 to 1.3.1 there are minor (backwards compatible
> changes)
> > to one package, with the other four having no API changes.
> > From 1.3.1 to 1.3.2 has no API changes, so is the micro version bump is
> > correct.
> >
> >  Looking at commons-math, there were major breaking changes to 6 packages
> > between versions  2.0 and 2.1.
> > There were five more packages with major level changes between 2.1 and
> > 2.2.  This was the second set of breaking changes for three of  of these
> > packages; their correct version number should have been 4.0.   Note that
> > this is *before* the packages prefix got changes to
> > org.apache.commons.math3
> >
> > The nature of the major changes in commons-math (mostly changing the
> return
> > types of methods) suggests that the developers might have used a
> different
> > approach rather than breaking binary compatibility.  To me, it seems that
> > automatically bumping the major version would have been the wrong
> response.
> >
> >
> > If you like, I can post a list of what the package version should have
> > been, assuming that every compatibility change was intentional, and
> > versioning was properly applied,  for  every bundle series under
> > org.apache.commons and commons-* that was on maven-central as of mid-may?
> >
> > Simon
> >
>



-- 
Matt Sicker 

Re: OSGi Version at Package Level

[Stefan Bodewig]

On 2017-06-07, Bertrand Delacretaz wrote:

> On Wed, Jun 7, 2017 at 9:10 AM, Emmanuel Bourg  wrote:
>> ...Do I understand well that we would have to micro manage versions at the
>> package level different from the version at the component level, and
>> sometimes significantly different versions (like foo 1.2.3 and
>> org.apache.commons.foo.bar 2.3.4)?...

> That's how it's done in OSGi-based systems.

>> ... That sounds like a nightmare...

> With the right tools as mentioned in my previous message it's quite easy.

>> ...What existing problem would that solve exactly?...

> Implementing semantic versioning at the java package level as opposed
> to bundle level.

> In heavily componentized systems that's a big help, assuming the Java
> packages make sense - to paraphrase Grady Booch, one package should do
> one thing and one thing well.

> On the other hand, if you don't care about package-level versioning
> and consider your bundle as one big thing on which other things
> depend, that doesn't help much.

Compress, which is targeted by Simon's pull request, is probably one of
the few components where package level versioning might make sense. For
most of our releases the packages are independent of each other and many
of our implementation packages don't change at all with new releases.

I'm not a citizen of OSGi land and find it hard to fully understand
whether the suggested changes make things better in any way.

Right now we bump all package level versions together with the
artifact. We intend to use semantic versioning, if we've failed to do so
in the past, then this is the problem more than whether the version
applies to the package or the library as a whole.

So I've got a bunch of practical questions:

Say we started versioning packages with 1.15 and all untouched APIs stay
at 1.14. We update package versions whenever there is an API change. We
go ahead and fix a problem with an implementation detail in - say - "ar"
in 1.19 but there is no API change. Would we modify the package version?

What if we change the implementation in "util", not in "ar", what is
going to happen to the version in "ar"? What will the bundle plugin tell
us?

Would this mean we'd need to start using bugfix version numbers for
packages where the implementaion changes but the API doesn't? I.e. "ar"
in Compress 1.19 would have version 1.14 (no API changes) or 1.14.5
(five implementation changes since 1.14)?

How would we tell our users to upgrade to version 1.19 in order to use a
bug fix that has been applied if this is the version of the library as a
whole and not the version of a package?

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: OSGI Version at Package Level : some more details about the COMPRESS-399 pull request

[Gary Gregory]

Is one upshot of this is that we should base the version number based on
this OSGi report tool?

Gary

On Jun 11, 2017 1:58 PM, "Simon Spero"  wrote:

> On Sun, Jun 11, 2017 at 3:16 PM, Gary Gregory 
> wrote:
>
> > My POV is that I only see a possible use cases for this in multi-module
> > components where one module defines an API and others different
> > implementation. Our release process is enough of a pain. Asking everyone
> > to consider if a change warrants a package version change is a pain. I
> still
> > do not see what practical and concrete problem this would solve for a
> > single module component. Granted COMPRESSA defines an API and
> > implementations all is one jar. But we work for 100% BC within a minor
> > release, so no problem there right? For BC breaks, we use a new version
> and
> > new package name, so no problem either, right?
> >
> > Can you show us a real problem that this would have solved? If not, write
> > up a realistic imaginary problem?
> >
>
> See: e.g http://www.sciencedirect.com/science/article/pii/
> S1571066111000399
>
> Note that the specific versions of *org.apache.commons.fileupload *are not
> completely on point, since as far as I know the first version of
> commons-fileupload to include bundle headers was 1.2.1
>
> However, we don't have to go much further to find more examples in that
> series.
> The bundles org.apache.commons.fileupload , version 1.2.*1*, and
>  org.apache.commons.fileupload, version 1.2.*2*  use the  same  version
> numbers for all packages, are two *micro* (aka bug-fix) version numbers
> within the same micro version.  Under  semantic versioning rules, micro
> versions must not have any API changes.
>
> However, between those 1.2.1 and 1.2.2, there are *minor* level changes to
> two of the five packages (the other three remain unchanged.
> Moving from version 1.2.2 to version 1.3.0,  there are *major* breaking
> binary changes to four packages (meaning they should have version 2.0.0).
> From version 1.3.0 to 1.3.1 there are minor (backwards compatible changes)
> to one package, with the other four having no API changes.
> From 1.3.1 to 1.3.2 has no API changes, so is the micro version bump is
> correct.
>
>  Looking at commons-math, there were major breaking changes to 6 packages
> between versions  2.0 and 2.1.
> There were five more packages with major level changes between 2.1 and
> 2.2.  This was the second set of breaking changes for three of  of these
> packages; their correct version number should have been 4.0.   Note that
> this is *before* the packages prefix got changes to
> org.apache.commons.math3
>
> The nature of the major changes in commons-math (mostly changing the return
> types of methods) suggests that the developers might have used a different
> approach rather than breaking binary compatibility.  To me, it seems that
> automatically bumping the major version would have been the wrong response.
>
>
> If you like, I can post a list of what the package version should have
> been, assuming that every compatibility change was intentional, and
> versioning was properly applied,  for  every bundle series under
> org.apache.commons and commons-* that was on maven-central as of mid-may?
>
> Simon
>

Re: OSGI Version at Package Level : some more details about the COMPRESS-399 pull request

[Simon Spero]

On Sun, Jun 11, 2017 at 3:16 PM, Gary Gregory 
wrote:

> My POV is that I only see a possible use cases for this in multi-module
> components where one module defines an API and others different
> implementation. Our release process is enough of a pain. Asking everyone
> to consider if a change warrants a package version change is a pain. I still
> do not see what practical and concrete problem this would solve for a
> single module component. Granted COMPRESSA defines an API and
> implementations all is one jar. But we work for 100% BC within a minor
> release, so no problem there right? For BC breaks, we use a new version and
> new package name, so no problem either, right?
>
> Can you show us a real problem that this would have solved? If not, write
> up a realistic imaginary problem?
>

See: e.g http://www.sciencedirect.com/science/article/pii/S1571066111000399

Note that the specific versions of *org.apache.commons.fileupload *are not
completely on point, since as far as I know the first version of
commons-fileupload to include bundle headers was 1.2.1

However, we don't have to go much further to find more examples in that
series.
The bundles org.apache.commons.fileupload , version 1.2.*1*, and
 org.apache.commons.fileupload, version 1.2.*2*  use the  same  version
numbers for all packages, are two *micro* (aka bug-fix) version numbers
within the same micro version.  Under  semantic versioning rules, micro
versions must not have any API changes.

However, between those 1.2.1 and 1.2.2, there are *minor* level changes to
two of the five packages (the other three remain unchanged.
Moving from version 1.2.2 to version 1.3.0,  there are *major* breaking
binary changes to four packages (meaning they should have version 2.0.0).
>From version 1.3.0 to 1.3.1 there are minor (backwards compatible changes)
to one package, with the other four having no API changes.
>From 1.3.1 to 1.3.2 has no API changes, so is the micro version bump is
correct.

 Looking at commons-math, there were major breaking changes to 6 packages
between versions  2.0 and 2.1.
There were five more packages with major level changes between 2.1 and
2.2.  This was the second set of breaking changes for three of  of these
packages; their correct version number should have been 4.0.   Note that
this is *before* the packages prefix got changes to org.apache.commons.math3

The nature of the major changes in commons-math (mostly changing the return
types of methods) suggests that the developers might have used a different
approach rather than breaking binary compatibility.  To me, it seems that
automatically bumping the major version would have been the wrong response.


If you like, I can post a list of what the package version should have
been, assuming that every compatibility change was intentional, and
versioning was properly applied,  for  every bundle series under
org.apache.commons and commons-* that was on maven-central as of mid-may?

Simon

Re: OSGI Version at Package Level : some more details about the COMPRESS-399 pull request

[Emmanuel Bourg]

Le 11/06/2017 à 21:16, Gary Gregory a écrit :

> Can you show us a real problem that this would have solved?
+1, I don't understand what actual issue it would solve with
commons-compress.

Emmanuel Bourg

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: OSGI Version at Package Level : some more details about the COMPRESS-399 pull request

[Gary Gregory]

My POV is that I only see a possible use cases for this in multi-module
components where one module defines an API and others different
implementation. Our release process is enough of a pain. Asking everyone to
consider if a change warrants a package version change is a pain. I still
do not see what practical and concrete problem this would solve for a
single module component. Granted COMPRESSA defines an API and
implementations all is one jar. But we work for 100% BC within a minor
release, so no problem there right? For BC breaks, we use a new version and
new package name, so no problem either, right?

Can you show us a real problem that this would have solved? If not, write
up a realistic imaginary problem?

Gary

On Jun 11, 2017 10:25 AM, "Simon Spero"  wrote:

So what's the current thinking on using compatibility-verified package
versioning  (for commons-* in general, but  COMPRESS-399 in particular?)

It doesn't take much work, and incorrect package versions cause real
problems.

*You added the headers and here I am. You tell 'em I'M coming... and Jar
Hell's coming with me, you hear?  **Jar Hell's coming with me!*


Simon

On Wed, Jun 7, 2017 at 5:02 PM, Gary Gregory  wrote:

> On Wed, Jun 7, 2017 at 10:28 AM, Simon Spero  wrote:
>
> > As Bertrand mentioned earlier, the bundle:baseline goal  is built in to
> the
> > maven-bundle-plugin already in use!
> >
> > The pull-request adds that goal to the verify phase of the maven build
> (and
> > changes the travis config to run 'mvn verify'  instead of 'mvn test' ).
> The
> > baseline goal is set to fail the build if the versioning contains
errors.
> >
>
> We should run mvn verify anyway to pick up any other checks like
> integration tests.
>
> Gary
>
>
> >
> > It takes very little work to bump the package version numbers when an
API
> > change is made.  The first time you change a package in a way that
> requires
> > a new version number, the build will simply break in the verify phase,
> with
> > a list of changes, and a suggested new version number.
> >
> > Any further API changes to the package at the same level or below will
> pass
> > the verify stage without a problem. For example, if you have already
> bumped
> > the package by a minor version, any further minor changes won't require
> any
> > more changes.
> >
> > However, a subsequent major (breaking) changes will fail when verifying.
> > The author of the change can then consider whether the breaking change
is
> > the best way forward, or whether their goals can be achieved in
different
> > way.Studies have shown that there is considerable confusion about what
is
> > and isn't a binary compatible change in java (for example, changing the
> > return type of a method from Collection to List is a
> > binary-incompatible change (but is source-compatible).  Breaking changes
> > need careful consideration.
> >
> > In principle, the major and minor components of the bundle & artifact
> > version should be bumped to match the most significant change in any
> > package in the bundle/artifact, so that maven version-range dependencies
> > don't break, but that ship has sunk.
> >
> > Simon
> > p.s.
> > The reason I'd been making changes to commons-compress was to support
> > creating and using random access tar.xz files in order to store release
> > series of  bundles from maven-central to investigate this issue (and see
> > how many problems can be fixed statically, and how many by dynamic
> > rewriting and/or fibbing.
> > p.p.s.
> > Compressing series of maven artifact is quite interesting ;
> >  for example, the ten releases of common-math3 (to 3.6) contain 40.9 MiB
> >  of uncompressed contents:
> >
> > 17.8 MiB as jars.
> >   6.4 MiB when the jars are packed in version order in .tar.xz format,
> >   4.4 MiB if the jars are run through pack200 and xz'ed individually.
> >   1.6 MiB if the compressed entries of the jar files are reflated first.
> >   1.5 MiB if run through pack200 then tar.xz
> >
>

Re: OSGI Version at Package Level : some more details about the COMPRESS-399 pull request

[Simon Spero]

So what's the current thinking on using compatibility-verified package
versioning  (for commons-* in general, but  COMPRESS-399 in particular?)

It doesn't take much work, and incorrect package versions cause real
problems.

*You added the headers and here I am. You tell 'em I'M coming... and Jar
Hell's coming with me, you hear?  **Jar Hell's coming with me!*


Simon

On Wed, Jun 7, 2017 at 5:02 PM, Gary Gregory  wrote:

> On Wed, Jun 7, 2017 at 10:28 AM, Simon Spero  wrote:
>
> > As Bertrand mentioned earlier, the bundle:baseline goal  is built in to
> the
> > maven-bundle-plugin already in use!
> >
> > The pull-request adds that goal to the verify phase of the maven build
> (and
> > changes the travis config to run 'mvn verify'  instead of 'mvn test' ).
> The
> > baseline goal is set to fail the build if the versioning contains errors.
> >
>
> We should run mvn verify anyway to pick up any other checks like
> integration tests.
>
> Gary
>
>
> >
> > It takes very little work to bump the package version numbers when an API
> > change is made.  The first time you change a package in a way that
> requires
> > a new version number, the build will simply break in the verify phase,
> with
> > a list of changes, and a suggested new version number.
> >
> > Any further API changes to the package at the same level or below will
> pass
> > the verify stage without a problem. For example, if you have already
> bumped
> > the package by a minor version, any further minor changes won't require
> any
> > more changes.
> >
> > However, a subsequent major (breaking) changes will fail when verifying.
> > The author of the change can then consider whether the breaking change is
> > the best way forward, or whether their goals can be achieved in different
> > way.Studies have shown that there is considerable confusion about what is
> > and isn't a binary compatible change in java (for example, changing the
> > return type of a method from Collection to List is a
> > binary-incompatible change (but is source-compatible).  Breaking changes
> > need careful consideration.
> >
> > In principle, the major and minor components of the bundle & artifact
> > version should be bumped to match the most significant change in any
> > package in the bundle/artifact, so that maven version-range dependencies
> > don't break, but that ship has sunk.
> >
> > Simon
> > p.s.
> > The reason I'd been making changes to commons-compress was to support
> > creating and using random access tar.xz files in order to store release
> > series of  bundles from maven-central to investigate this issue (and see
> > how many problems can be fixed statically, and how many by dynamic
> > rewriting and/or fibbing.
> > p.p.s.
> > Compressing series of maven artifact is quite interesting ;
> >  for example, the ten releases of common-math3 (to 3.6) contain 40.9 MiB
> >  of uncompressed contents:
> >
> > 17.8 MiB as jars.
> >   6.4 MiB when the jars are packed in version order in .tar.xz format,
> >   4.4 MiB if the jars are run through pack200 and xz'ed individually.
> >   1.6 MiB if the compressed entries of the jar files are reflated first.
> >   1.5 MiB if run through pack200 then tar.xz
> >
>

Re: OSGI Version at Package Level : some more details about the COMPRESS-399 pull request

[Gary Gregory]

On Wed, Jun 7, 2017 at 10:28 AM, Simon Spero  wrote:

> As Bertrand mentioned earlier, the bundle:baseline goal  is built in to the
> maven-bundle-plugin already in use!
>
> The pull-request adds that goal to the verify phase of the maven build (and
> changes the travis config to run 'mvn verify'  instead of 'mvn test' ). The
> baseline goal is set to fail the build if the versioning contains errors.
>

We should run mvn verify anyway to pick up any other checks like
integration tests.

Gary


>
> It takes very little work to bump the package version numbers when an API
> change is made.  The first time you change a package in a way that requires
> a new version number, the build will simply break in the verify phase, with
> a list of changes, and a suggested new version number.
>
> Any further API changes to the package at the same level or below will pass
> the verify stage without a problem. For example, if you have already bumped
> the package by a minor version, any further minor changes won't require any
> more changes.
>
> However, a subsequent major (breaking) changes will fail when verifying.
> The author of the change can then consider whether the breaking change is
> the best way forward, or whether their goals can be achieved in different
> way.Studies have shown that there is considerable confusion about what is
> and isn't a binary compatible change in java (for example, changing the
> return type of a method from Collection to List is a
> binary-incompatible change (but is source-compatible).  Breaking changes
> need careful consideration.
>
> In principle, the major and minor components of the bundle & artifact
> version should be bumped to match the most significant change in any
> package in the bundle/artifact, so that maven version-range dependencies
> don't break, but that ship has sunk.
>
> Simon
> p.s.
> The reason I'd been making changes to commons-compress was to support
> creating and using random access tar.xz files in order to store release
> series of  bundles from maven-central to investigate this issue (and see
> how many problems can be fixed statically, and how many by dynamic
> rewriting and/or fibbing.
> p.p.s.
> Compressing series of maven artifact is quite interesting ;
>  for example, the ten releases of common-math3 (to 3.6) contain 40.9 MiB
>  of uncompressed contents:
>
> 17.8 MiB as jars.
>   6.4 MiB when the jars are packed in version order in .tar.xz format,
>   4.4 MiB if the jars are run through pack200 and xz'ed individually.
>   1.6 MiB if the compressed entries of the jar files are reflated first.
>   1.5 MiB if run through pack200 then tar.xz
>

Re: OSGi Version at Package Level

[Gilles]

On Wed, 7 Jun 2017 10:54:54 +0100, sebb wrote:
On 7 June 2017 at 09:02, Bertrand Delacretaz  
wrote:
On Wed, Jun 7, 2017 at 9:57 AM, Emmanuel Bourg  
wrote:

Le 7/06/2017 à 09:23, Bertrand Delacretaz a écrit :
... Implementing semantic versioning at the java package level as 
opposed

to bundle level.


That's the theory, I'm actually curious to see what real issue it 
solves

with commons-compress


I agree that what I explained is "the theory" which is very valid in
complex systems fully based on OSGi, avoiding problems if for 
example

an API package is provided by multiple bundles.

But maybe it doesn't make sense for commons-compress, I don't know
that code well enough to comment.


I doubt package-level versions make sense for (m)any Commons 
components.

AFAIK most components are only usable and released as a whole.


It would have made sense in a certain component that is so big that
many parts of it did not fundamentally change between two releases,
yet where bumped into a different top-level package because other
parts required an incompatible release.

For a single "real" component (small scope), it is not necessary,
almost by definition.

For a bunch of utilities, e.g. (maven) modules, that can evolve
independently or at different paces, it seems like a neat idea.
[As was explained by Stian some time ago (when I had proposed to
allow module versions, it is a political decision, not a technical
one.]


Regards,
Gilles



It might make sense for VFS I suppose, if that wants to release
implementations separately.


-Bertrand




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: OSGi Version at Package Level

[sebb]

On 7 June 2017 at 09:02, Bertrand Delacretaz  wrote:
> On Wed, Jun 7, 2017 at 9:57 AM, Emmanuel Bourg  wrote:
>> Le 7/06/2017 à 09:23, Bertrand Delacretaz a écrit :
>>>... Implementing semantic versioning at the java package level as opposed
>>> to bundle level.
>>
>> That's the theory, I'm actually curious to see what real issue it solves
>> with commons-compress
>
> I agree that what I explained is "the theory" which is very valid in
> complex systems fully based on OSGi, avoiding problems if for example
> an API package is provided by multiple bundles.
>
> But maybe it doesn't make sense for commons-compress, I don't know
> that code well enough to comment.

I doubt package-level versions make sense for (m)any Commons components.
AFAIK most components are only usable and released as a whole.

It might make sense for VFS I suppose, if that wants to release
implementations separately.

> -Bertrand
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: OSGi Version at Package Level

[Bertrand Delacretaz]

On Wed, Jun 7, 2017 at 9:57 AM, Emmanuel Bourg  wrote:
> Le 7/06/2017 à 09:23, Bertrand Delacretaz a écrit :
>>... Implementing semantic versioning at the java package level as opposed
>> to bundle level.
>
> That's the theory, I'm actually curious to see what real issue it solves
> with commons-compress

I agree that what I explained is "the theory" which is very valid in
complex systems fully based on OSGi, avoiding problems if for example
an API package is provided by multiple bundles.

But maybe it doesn't make sense for commons-compress, I don't know
that code well enough to comment.

-Bertrand

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: OSGi Version at Package Level

[Emmanuel Bourg]

Le 7/06/2017 à 09:23, Bertrand Delacretaz a écrit :

> With the right tools as mentioned in my previous message it's quite easy.

Easier but not easy.


> Implementing semantic versioning at the java package level as opposed
> to bundle level.

That's the theory, I'm actually curious to see what real issue it solves
with commons-compress. What incompatibility in commons-compress caused
an issue with an OSGi application? And was there no other alternative to
solve this issue?

Emmanuel Bourg

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: OSGi Version at Package Level

[Bertrand Delacretaz]

On Wed, Jun 7, 2017 at 9:10 AM, Emmanuel Bourg  wrote:
> ...Do I understand well that we would have to micro manage versions at the
> package level different from the version at the component level, and
> sometimes significantly different versions (like foo 1.2.3 and
> org.apache.commons.foo.bar 2.3.4)?...

That's how it's done in OSGi-based systems.

>... That sounds like a nightmare...

With the right tools as mentioned in my previous message it's quite easy.

> ...What existing problem would that solve exactly?...

Implementing semantic versioning at the java package level as opposed
to bundle level.

In heavily componentized systems that's a big help, assuming the Java
packages make sense - to paraphrase Grady Booch, one package should do
one thing and one thing well.

On the other hand, if you don't care about package-level versioning
and consider your bundle as one big thing on which other things
depend, that doesn't help much.

-Bertrand

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: OSGi Version at Package Level

[Emmanuel Bourg]

Le 7/06/2017 à 02:10, Jörg Schaible a écrit :

> Your opinions?

Do I understand well that we would have to micro manage versions at the
package level different from the version at the component level, and
sometimes significantly different versions (like foo 1.2.3 and
org.apache.commons.foo.bar 2.3.4)? That sounds like a nightmare. What is
the real gain? What existing problem would that solve exactly?

Emmanuel Bourg

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: OSGi Version at Package Level

[Bertrand Delacretaz]

Hi,

On Wed, Jun 7, 2017 at 2:10 AM, Jörg Schaible  wrote:
> ...maybe you have missed the discussion for
> https://issues.apache.org/jira/browse/COMPRESS-399, but in short we face a
> PR that introduces individual versions at package level for a component

That's standard practice for OSGi bundles.

The https://github.com/apache/commons-compress/pull/26 changes look
suboptimal because they set the same initial version for each exported
package, but that's correct as a way to start doing that.

The "baseline" goal of the Apache Felix maven-bundle-plugin can then
be used to automatically recommend changes to those version numbers to
implement semantic versioning *at the java package level* which is the
way OSGi handles this.

We're using this extensively in Apache Sling, where we release a large
number of bundles each with their own package-level version numbers
which evolve independently from the bundle version. It works well once
it's setup, which is what that pull/26 does AFAICS.

Here's example output from that plugin building [1] after adding a
method to a class in the o.a.s.distribution package:

[INFO] Baseline Report - Generated by Apache Felix Maven Bundle Plugin
on 2017-06-07T08:54Z based on Bnd - see http://www.aqute.biz/Bnd/Bnd
[INFO] Comparing bundle org.apache.sling.distribution.api version
0.3.1-SNAPSHOT to version 0.3.0
[INFO]
[INFO]   PACKAGE_NAME   DELTA
CUR_VERBASE_VER   REC_VERWARNINGS
[INFO] = == ==
== == == ==
[INFO] * org.apache.sling.distribution  minor
0.3.0  0.3.0  0.4.0  Version increase required
[INFO]  < interface org.apache.sling.distribution.Distributor
[INFO]  + method doNothing()
[INFO]  + access abstract
[INFO] 
---
[INFO]   org.apache.sling.distribution.eventunchanged
0.1.1  0.1.1  0.1.1  -
[INFO] 
---
[INFO]   org.apache.sling.distribution.transportunchanged
0.1.0  0.1.0  0.1.0  -
[INFO] 
---
[ERROR] org.apache.sling.distribution: Version increase required;
detected 0.3.0, suggested 0.4.0
[INFO] Baseline analysis complete, 1 error(s), 0 warning(s)

HTH,
-Bertrand

[1] 
https://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/distribution/api

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: OSGi Version at Package Level

[Gary Gregory]

On Tue, Jun 6, 2017 at 5:10 PM, Jörg Schaible  wrote:

> Hi,
>
> maybe you have missed the discussion for
> https://issues.apache.org/jira/browse/COMPRESS-399, but in short we face a
> PR that introduces individual versions at package level for a component.
>
> Actually I can understand the reasoning from a logical point if view, but
> it
> fails for me completely from the practical side. Do we really want
> different
> versions inside a single component? Can we even guarantee binary
> compatibility to such an extent? Do we want such a micro-management for
> each
> release?
>
> IMHO it does not make sense, our release process is enervating enough.
> Until
> now we provide one version for each release that is also valid for OSGi. I
> have not too much experience with OSGi myself, but when I look into the
> Eclipse ecosystem then I can see that a complete bunch of plugins is
> released together as one version - I am not aware that they do such package
> based version management. And - AFACIS - it is also possible to declare
> valid ranges for OSGi dependencies. And we ensure with our release policy
> for major versions (new package name) that no dependency can upgraded by
> pure chance to a major incompatible version.
>
> I won't put a veto on the commit of this PR, but actually I am not
> interesting in supporting such a scenario for our components.
>
> Your opinions?
>

It sounds like a maintenance nightmare.

Is there at least a Maven plugin to help like Clirr and japicmp, but for
OSGi?

Gary


>
> Cheers,
> Jörg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>