BND Import Version Policy

[Felix Meschberger]

Hi,

On [1] I read the default import version policies to be:

-provider-policy : ${range;[==,=+)}
-consumer-policy : ${range;[==,+)}

This sets the lower bound for an API import to major and minor version.

We now have a library (Apache Sling Auth Core [2]) which exports a
package at version 1.0.4. This version added a static method to an
abstract class hence we increased the micro version since the abstrac
API didn't and thus providers are still compatible.

We now have such a provider depending on this new method and the import
should therefore be for 1.0.4, yet the default policies call for 1.0
which causes a runtime MethodNotFoundError ...

I wonder, whether the default policies should rather be

-provider-policy : ${range;[===,=+)}
-consumer-policy : ${range;[===,+)}

thus adding the micro version to the lower bound ?

Regards
Felix

[1]
http://svn.apache.org/repos/asf/sling/trunk/bundles/auth/core/pom.xml
[2] http://www.aqute.biz/Bnd/Versioning

[Peter Kriens]

Well, then you loose the advantage of the micro, as it becomes different to the minor. I think this change is a minor change. Only changes that are not visible to the consumer nor provider can be micro.

provider & consumer depends on the change major
provider depends on the change, not consumer minor
nobody depends on the change micro
build qualifier

The micro case, which you used, is for spelling errors, impl. bug fixes, but cannot have anything visible to either a provider or a consumer.

Obviously you can use your own policy but I think that merging micro and minor is not a good idea?

Kind regards,

Peter Kriens

[Felix Meschberger]

Hi Peter,

Thanks for the feedback.

Am Freitag, den 26.08.2011, 07:00 +0100 schrieb Peter Kriens:
> Well, then you loose the advantage of the micro, as it becomes different to the minor. I think this change is a minor change. Only changes that are not visible to the consumer nor provider can be micro.
>
> provider & consumer depends on the change major
> provider depends on the change, not consumer minor

This is where it becomes tricky IMHO.

I agree that adding a new abstract method to be implemented by a
provider constitutes a minor version increase. But is this a
"dependency" ? I'd rather call it a "requirement" on the provider.

My change was to add a new fully implemented method, which may be
consumed by consumers and providers the like. So existing providers are
can safely ignore that change but providers can leverage it. This really
is a dependency.

> nobody depends on the change micro
> build qualifier
>
> The micro case, which you used, is for spelling errors, impl. bug fixes, but cannot have anything visible to either a provider or a consumer.
>
> Obviously you can use your own policy but I think that merging micro and minor is not a good idea?

I don't want to merge, I want to keep them separate but use the
minor-micro combo the same way for producers as we are used to use the
major-minor combo for consumers:

Consumers:
Major causes implementation work
Minor brings new API for use

Producers:
Minor causes implementation work
Micro brings new API for use

I understand it as kind of like a refinement allowing producers to also
act as consumers to certain parts of the exported package.

Regards
Felix

[Peter Kriens]

On 26 aug 2011, at 08:15, Felix Meschberger wrote:

> Hi Peter,
> Thanks for the feedback.

Thanks for the question, this is an interesting area.

> Am Freitag, den 26.08.2011, 07:00 +0100 schrieb Peter Kriens:
>> Well, then you loose the advantage of the micro, as it becomes different to the minor. I think this change is a minor change. Only changes that are not visible to the consumer nor provider can be micro.
>> provider & consumer depends on the change major
>> provider depends on the change, not consumer minor
> This is where it becomes tricky IMHO.
> I agree that adding a new abstract method to be implemented by a
> provider constitutes a minor version increase. But is this a
> "dependency" ? I'd rather call it a "requirement" on the provider.

> My change was to add a new fully implemented method, which may be
> consumed by consumers and providers the like. So existing providers are
> can safely ignore that change but providers can leverage it. This really
> is a dependency.

Aren't you contradicting yourself? :-)

>> nobody depends on the change micro
>> build qualifier
>>
>> The micro case, which you used, is for spelling errors, impl. bug fixes, but cannot have anything visible to either a provider or a consumer.
>>
>> Obviously you can use your own policy but I think that merging micro and minor is not a good idea?
> I don't want to merge, I want to keep them separate but use the
> minor-micro combo the same way for producers as we are used to use the
> major-minor combo for consumers:

> Consumers:
> Major causes implementation work
> Minor brings new API for use
>
> Producers:
> Minor causes implementation work
> Micro brings new API for use
> I understand it as kind of like a refinement allowing producers to also
> act as consumers to certain parts of the exported package.

The problem then is how to version something does not affect the provider? I.e. a spelling error in the doc or a bug fix in the impl. code?

And in this case anyway, can the consumer not see the change as well?

Kind regards,

Peter Kriens

[Felix Meschberger]

Hi

Am Freitag, den 26.08.2011, 07:52 +0100 schrieb Peter Kriens:
> On 26 aug 2011, at 08:15, Felix Meschberger wrote:
>
> > Hi Peter,
> > Thanks for the feedback.
> Thanks for the question, this is an interesting area.

Indeed. And I think there is no solution helping everybody ...

>
> > Am Freitag, den 26.08.2011, 07:00 +0100 schrieb Peter Kriens:
> >> Well, then you loose the advantage of the micro, as it becomes different to the minor. I think this change is a minor change. Only changes that are not visible to the consumer nor provider can be micro.
> >> provider & consumer depends on the change major
> >> provider depends on the change, not consumer minor
> > This is where it becomes tricky IMHO.
> > I agree that adding a new abstract method to be implemented by a
> > provider constitutes a minor version increase. But is this a
> > "dependency" ? I'd rather call it a "requirement" on the provider.
>
> > My change was to add a new fully implemented method, which may be
> > consumed by consumers and providers the like. So existing providers are
> > can safely ignore that change but providers can leverage it. This really
> > is a dependency.
> Aren't you contradicting yourself? :-)

I don't think so ;-)

> >> nobody depends on the change micro
> >> build qualifier
> >>
> >> The micro case, which you used, is for spelling errors, impl. bug fixes, but cannot have anything visible to either a provider or a consumer.
> >>
> >> Obviously you can use your own policy but I think that merging micro and minor is not a good idea?
> > I don't want to merge, I want to keep them separate but use the
> > minor-micro combo the same way for producers as we are used to use the
> > major-minor combo for consumers:
>
> > Consumers:
> > Major causes implementation work
> > Minor brings new API for use
> >
> > Producers:
> > Minor causes implementation work
> > Micro brings new API for use
> > I understand it as kind of like a refinement allowing producers to also
> > act as consumers to certain parts of the exported package.
> The problem then is how to version something does not affect the provider? I.e. a spelling error in the doc or a bug fix in the impl. code?

That would maybe require a non-qualifier-sub-micro (nano ?) version. But
we can't probably do that without breaking almost everything.

>
> And in this case anyway, can the consumer not see the change as well?

I think the problem lies with one provider wishing to make use of the
new concrete method and other providers not caring (and not being
broken).

Maybe at the end of the day it is a question of who has to pay the price
for being able to consume new concrete API: The consumer (my proposal
increasing the micro version thus causing the consumer to explicitly
state this) or the producer (the current versioning policy setup) ?

I see your point. But probably, unless we get a new nano version or
retarget the qualifier version, we won't get a fully satisfactory
solution. Actually neither adding nano nor retargetting the qualifier is
satisfactory, either....

Until then I hold that my proposal is the best of all sub-optimal
solutions: Consumers and producers can require and use the new concrete
API but none is broken if they don't care. At the expense of blurring
the definition of the micro version.

[Peter Kriens]

About the contradiction:

- But is this a "dependency" ? I'd rather call it a "requirement" on the provider. 

- ... can safely ignore that change but providers can leverage it. This really is a dependency.

I think your use case is a valid one but too special. Such things should not be common practice. So in your case, I would just override the Import-Pacakge of your provider to include the minor.

Import-Package: my.anally.versioned.package;version= ${range;[===,=+)}, *

Making it the standard is a bit too subtle for me, but hey, I can always be convinced. :-)

Kind regards,

Peter Kriens

[Felix Meschberger]

Hi,

Am Freitag, den 26.08.2011, 09:18 +0100 schrieb Peter Kriens:
> About the contradiction:
>
>
> - But is this a "dependency" ? I'd rather call it a "requirement" on
> the provider.
> - ... can safely ignore that change but providers can leverage it.
> This really is a dependency.
>

Ah I see. This sounds like extremely bad formulation.

>
>
> I think your use case is a valid one but too special. Such things
> should not be common practice. So in your case, I would just override
> the Import-Pacakge of your provider to include the minor.
>
>
> Import-Package: my.anally.versioned.package;version= ${range;[===,=
> +)}, *
>
>
>
>
> Making it the standard is a bit too subtle for me, but hey, I can
> always be convinced. :-)

Ok; not sure, whether I succeed in convincing you here and now. Maybe
over a beer or two ;-)

But I think I can make it the default in my projects, because:
* I use Maven
* and I use the least version of a dependency which still provides the
required functionality

Thus I can "guarantee" that I get the least lower bound for my version
range which satisfies the bundle's needs.

Thanks again your feedback.

[Peter Kriens]

You really want the last word don't you? :-)

Kind regards,

Peter Kriens