Semantic Versioning tool

[Emily Jiang <em...@googlemail.com>]

I have developed a semantic checking tool to check whether a bundle's
version or the export package versions are correclty versioned according to
OSGi semantic versioning whitepaper. I would like to contribute to Apache
Aries as subproject under a code name of 'llama' ( or a better name. I am
open to suggestions).

Any thoughts or suggestions?
-- 
Thanks
Emily
=================
Emily Jiang
ejiang@apache.org

Re: Semantic Versioning tool

[Jeremy Hughes <hu...@apache.org>]

On 28 September 2011 16:58, Emily Jiang <em...@googlemail.com> wrote:
> Hi David,
>
> It works by comparing the current binary with the baseline binary:
> 1. For each export package, it scans each non private class to see whether
> there are binary incompatibility changes (according to Java specificiation
> chapter 13 Binary Compability). If yes, a major version change is needed for
> this pkg.
> 2. If there are not binary incompability changes, it will see whether there
> are abstract class, methods or new xsd file added. If yes, the package's
> minor version needs to be increased.
> 3. It then determine the bundle version based on package versions changed
> according to semantic versioning white paper.

>From what I know of it (I work with Emily) it doesn't do any
'semantic' checking, just syntactic checking :-)

>
> The tool ignore micro version changes.
>
> I can contribute the tool as a project and then we can create a mvn plugin
> from it or something even smarter.
>
> Regards,
> Emily
>
> On Wed, Sep 28, 2011 at 4:16 PM, David Bosschaert <
> david.bosschaert@gmail.com> wrote:
>
>> Very interesting, Emily. Would you be able to provide some information
>> regarding how it works?
>>
>> In any case I would welcome such an addition to Aries.
>>
>> Best regards,
>>
>> David
>>
>> On 28 September 2011 16:02, Emily Jiang <em...@googlemail.com> wrote:
>> > I have developed a semantic checking tool to check whether a bundle's
>> > version or the export package versions are correclty versioned according
>> to
>> > OSGi semantic versioning whitepaper. I would like to contribute to Apache
>> > Aries as subproject under a code name of 'llama' ( or a better name. I am
>> > open to suggestions).
>> >
>> > Any thoughts or suggestions?
>> > --
>> > Thanks
>> > Emily
>> > =================
>> > Emily Jiang
>> > ejiang@apache.org
>> >
>>
>
>
>
> --
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang@apache.org
>

Re: Semantic Versioning tool

[Alasdair Nottingham <no...@apache.org>]

Alasdair Nottingham

On 30 Sep 2011, at 17:11, Jeremy Hughes <hu...@apache.org> wrote:

> On 30 September 2011 15:00, Alasdair Nottingham <no...@apache.org> wrote:
>> Hi
>> 
>> I think David is right on this one. If we look at ConfigAdmin as an example.
>> The ConfigAdmin interface contains two interfaces (well it contains more,
>> but two of import to my example):
>> 
>> ConfigurationAdmin
>> ConfigurationListener
>> 
>> A ConfigAdmin implementation implements ConfigAdmin. In this example adding
>> a method to ConfigurationAdmin constitute a "compatible" change. i.e. a user
>> of the service does not care. However adding a method to
>> ConfigurationListener would constitute a major version change. This is
>> because ConfigurationAdmin is to be used by clients of the spec and
>> ConfigurationListener to be implemented by them.
>> 
>> It really relates whether the implementor of the interface is a "provider"
>> or a "user" of the package. I'm not sure this is well explained :(
> 
> I think it's "provider" vs "consumer". It strikes me the paper needed
> to distinguish between changes to provider implemented interfaces and
> consumer implemented interfaces in this way because there's never been
> any advice to separate interfaces used in these distinctly different
> ways, into separate packages. And because there *are* packages with
> these two types of interface in the same package, particularly in OSGi
> standard packages, the advice had to be what it is - so that adding a
> method to EventAdmin, causing a minor version increment to the
> package, wouldn't unnecessarily break consumers of EventListener, for
> example.
> 
> If provider implemented interfaces were always in different packages
> to consumer implemented interfaces, the rule could just be: if the
> interface author changes the interface in a binary compatible way that
> requires implementors to make changes, then the minor version should
> be incremented; (also, of course, major version increments for binary
> incompatible changes). The problem is, there *are* packages out there
> that need to be versioned which include interfaces both for consumers
> and providers.

While this is an option it is not one that fills me with enthusiasm. It is a Hugh change to the way we design and use packages. Typically types in a package have cohesion and, as an example, a listener, event and the type you register it with has cohesion. I think we need to work with existing conventions rather than try to force new design schemes.

> Sigh. So pragmatically the only way to go is to
> introduce a new mechanism as you suggest below to indicate which
> interfaces are for consumers and which for providers. I think though,
> it would be useful for the annotation mechanism to be standardized.
> 

I agree, the OSGi alliance uses an @noimplement tag to mark types that a client uses, rather than implements. I think I've also seen an @userimplements tag for the opposite. I think we can also look for common naming conventions like XYZListener would probably be user implemented. The issue with javadoc tags is that you need the source which you might not have. 

>> 
>> How we "detect this" might be tough, but we have a good starting point. We
>> could look at the source for javadoc tags @userimplements or we could
>> provide annotations, or allow configuration to say "this is user
>> implementable stuff".
> 
> Yeah, all of these work for me.
> 
>> 
>> Alasdair
>> 
>> On 29 September 2011 14:30, Jeremy Hughes <hu...@apache.org> wrote:
>> 
>>> On 29 September 2011 12:25, David Bosschaert <da...@gmail.com>
>>> wrote:
>>>> On 29 September 2011 11:58, Jeremy Hughes <hu...@apache.org> wrote:
>>> [snip]
>>>>> 
>>>>> I think it's on a package level, not a technology level.
>>>>> 
>>>>> To quote the white paper (executive summary):
>>>>> 
>>>>> "A package can contain an API. There are two types of clients for
>>>>> these API packages: API consumers and API
>>>>> implementation providers. A change in the second (minor) part of the
>>>>> version signals that the change is
>>>>> backward compatible with consumers of the API package but not with the
>>>>> providers of that API. That is,
>>>>> when the API package goes from version 1.5 to 1.6 it is no longer
>>>>> compatible with a provider of that API but
>>>>> consumers of that API are backward compatible with that API package."
>>>>> 
>>>>> An implementer of BlueprintListener is an API implementation provider.
>>>>> A single class can be an API implementation provider of
>>>>> BlueprintListener while being an API consumer of other blueprint
>>>>> packages. I don't believe the whitepaper describes the subtlety you
>>>>> allude to. Have I missed something?
>>>> 
>>>> And again, I may have missed something here too :) The situation that
>>>> I'm describing here is that *within* a single package (e.g. the
>>>> org.osgi.service.blueprint.container package to stay with our example)
>>>> one could be a consumer while still implementing an API provided by
>>>> that package.
>>>> 
>>>> That's why when in our example when
>>>> org.osgi.service.blueprint.container.BlueprintContainer gets a new
>>>> method only the minor version of the package needs to be increased (as
>>>> consumers don't implement this interface) but when
>>>> org.osgi.service.blueprint.container.BlueprintListener gets a new
>>>> method the major version of the package needs to be increased as
>>>> consumers do implement this interface, but given they're a consumer
>>>> should be allowed to specify a version range like [1.0.0, 2.0.0).
>>> 
>>> I see what you mean and the whitepaper discusses this scenario in the
>>> 4th para of p8:
>>> 
>>> "An interesting problem for exporters is the policy applied to
>>> interfaces that are implemented by the consumers of the API. For
>>> example, in the OSGi framework, the Bundle Activator interface is not
>>> implemented by a framework provider but by consumers of the framework
>>> API: bundles. A change in such an interface will not be backward
>>> compatible with any consumers of the API and therefore requires a
>>> change in the major part of the version. API designers must therefore
>>> be acutely aware of the usage pattern of their interfaces and try to
>>> prevent making changes to interfaces that are implemented by the
>>> consumers of the API. Any change in an interface that is implemented
>>> by a consumer of the API breaks backward compatibility for all
>>> consumers."
>>> 
>>> Oddly, this conflicts with the 2nd para of p8:
>>> 
>>> "Tools will be able to detect syntactic violations of the semantic
>>> versioning by comparing a previous version and the new version."
>>> 
>>> A tool cannot determine whether an interface in an exported package is
>>> being exported for consumers or for implementers. There's no standard
>>> way of doing so. Moreover, if there was, it wouldn't be enforceable at
>>> compile time without changes to the compiler. A tool doesn't have
>>> visibility to all the possible importers of the package. It therefore
>>> cannot say whether a package is being used by consumers or
>>> implementers ... or both!!
>>> 
>>> IMHO the whitepaper attempts to protect consumers too vigorously. A
>>> better arrangement would be for the exporter to modify the minor or
>>> major version based on changes to the interface(s) in the package
>>> rather than what an importer might decide what to do with it. (since I
>>> already mentioned declaring what an importer can / cannot do with it
>>> is unenforceable). There's nothing wrong with consumers being mindful
>>> of what packages they import for interfaces they wish to implement and
>>> set their import version ranges appropriately.
>>> 
>>> So:
>>> 
>>> a) the white paper is in conflict with itself para 2 vs 4 on p8
>>> b) what is proposed in para 4 cannot be implemented by tools, so will
>>> be ignored by tools providers and will eventually fall by the wayside
>>> 
>>> I guess now, I'm posting to the wrong list as this should be a
>>> discussion with the paper's authors ;-)
>>> 
>>>> 
>>>> Cheers,
>>>> 
>>>> David
>>>> 
>>> 
>> 
>> 
>> 
>> --
>> Alasdair Nottingham
>> not@apache.org
>> 

Re: Semantic Versioning tool

[Jeremy Hughes <hu...@apache.org>]

On 30 September 2011 15:00, Alasdair Nottingham <no...@apache.org> wrote:
> Hi
>
> I think David is right on this one. If we look at ConfigAdmin as an example.
> The ConfigAdmin interface contains two interfaces (well it contains more,
> but two of import to my example):
>
> ConfigurationAdmin
> ConfigurationListener
>
> A ConfigAdmin implementation implements ConfigAdmin. In this example adding
> a method to ConfigurationAdmin constitute a "compatible" change. i.e. a user
> of the service does not care. However adding a method to
> ConfigurationListener would constitute a major version change. This is
> because ConfigurationAdmin is to be used by clients of the spec and
> ConfigurationListener to be implemented by them.
>
> It really relates whether the implementor of the interface is a "provider"
> or a "user" of the package. I'm not sure this is well explained :(

I think it's "provider" vs "consumer". It strikes me the paper needed
to distinguish between changes to provider implemented interfaces and
consumer implemented interfaces in this way because there's never been
any advice to separate interfaces used in these distinctly different
ways, into separate packages. And because there *are* packages with
these two types of interface in the same package, particularly in OSGi
standard packages, the advice had to be what it is - so that adding a
method to EventAdmin, causing a minor version increment to the
package, wouldn't unnecessarily break consumers of EventListener, for
example.

If provider implemented interfaces were always in different packages
to consumer implemented interfaces, the rule could just be: if the
interface author changes the interface in a binary compatible way that
requires implementors to make changes, then the minor version should
be incremented; (also, of course, major version increments for binary
incompatible changes). The problem is, there *are* packages out there
that need to be versioned which include interfaces both for consumers
and providers. Sigh. So pragmatically the only way to go is to
introduce a new mechanism as you suggest below to indicate which
interfaces are for consumers and which for providers. I think though,
it would be useful for the annotation mechanism to be standardized.

>
> How we "detect this" might be tough, but we have a good starting point. We
> could look at the source for javadoc tags @userimplements or we could
> provide annotations, or allow configuration to say "this is user
> implementable stuff".

Yeah, all of these work for me.

>
> Alasdair
>
> On 29 September 2011 14:30, Jeremy Hughes <hu...@apache.org> wrote:
>
>> On 29 September 2011 12:25, David Bosschaert <da...@gmail.com>
>> wrote:
>> > On 29 September 2011 11:58, Jeremy Hughes <hu...@apache.org> wrote:
>> [snip]
>> >>
>> >> I think it's on a package level, not a technology level.
>> >>
>> >> To quote the white paper (executive summary):
>> >>
>> >> "A package can contain an API. There are two types of clients for
>> >> these API packages: API consumers and API
>> >> implementation providers. A change in the second (minor) part of the
>> >> version signals that the change is
>> >> backward compatible with consumers of the API package but not with the
>> >> providers of that API. That is,
>> >> when the API package goes from version 1.5 to 1.6 it is no longer
>> >> compatible with a provider of that API but
>> >> consumers of that API are backward compatible with that API package."
>> >>
>> >> An implementer of BlueprintListener is an API implementation provider.
>> >> A single class can be an API implementation provider of
>> >> BlueprintListener while being an API consumer of other blueprint
>> >> packages. I don't believe the whitepaper describes the subtlety you
>> >> allude to. Have I missed something?
>> >
>> > And again, I may have missed something here too :) The situation that
>> > I'm describing here is that *within* a single package (e.g. the
>> > org.osgi.service.blueprint.container package to stay with our example)
>> > one could be a consumer while still implementing an API provided by
>> > that package.
>> >
>> > That's why when in our example when
>> > org.osgi.service.blueprint.container.BlueprintContainer gets a new
>> > method only the minor version of the package needs to be increased (as
>> > consumers don't implement this interface) but when
>> > org.osgi.service.blueprint.container.BlueprintListener gets a new
>> > method the major version of the package needs to be increased as
>> > consumers do implement this interface, but given they're a consumer
>> > should be allowed to specify a version range like [1.0.0, 2.0.0).
>>
>> I see what you mean and the whitepaper discusses this scenario in the
>> 4th para of p8:
>>
>> "An interesting problem for exporters is the policy applied to
>> interfaces that are implemented by the consumers of the API. For
>> example, in the OSGi framework, the Bundle Activator interface is not
>> implemented by a framework provider but by consumers of the framework
>> API: bundles. A change in such an interface will not be backward
>> compatible with any consumers of the API and therefore requires a
>> change in the major part of the version. API designers must therefore
>> be acutely aware of the usage pattern of their interfaces and try to
>> prevent making changes to interfaces that are implemented by the
>> consumers of the API. Any change in an interface that is implemented
>> by a consumer of the API breaks backward compatibility for all
>> consumers."
>>
>> Oddly, this conflicts with the 2nd para of p8:
>>
>> "Tools will be able to detect syntactic violations of the semantic
>> versioning by comparing a previous version and the new version."
>>
>> A tool cannot determine whether an interface in an exported package is
>> being exported for consumers or for implementers. There's no standard
>> way of doing so. Moreover, if there was, it wouldn't be enforceable at
>> compile time without changes to the compiler. A tool doesn't have
>> visibility to all the possible importers of the package. It therefore
>> cannot say whether a package is being used by consumers or
>> implementers ... or both!!
>>
>> IMHO the whitepaper attempts to protect consumers too vigorously. A
>> better arrangement would be for the exporter to modify the minor or
>> major version based on changes to the interface(s) in the package
>> rather than what an importer might decide what to do with it. (since I
>> already mentioned declaring what an importer can / cannot do with it
>> is unenforceable). There's nothing wrong with consumers being mindful
>> of what packages they import for interfaces they wish to implement and
>> set their import version ranges appropriately.
>>
>> So:
>>
>> a) the white paper is in conflict with itself para 2 vs 4 on p8
>> b) what is proposed in para 4 cannot be implemented by tools, so will
>> be ignored by tools providers and will eventually fall by the wayside
>>
>> I guess now, I'm posting to the wrong list as this should be a
>> discussion with the paper's authors ;-)
>>
>> >
>> > Cheers,
>> >
>> > David
>> >
>>
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
>

Re: Semantic Versioning tool

[Alasdair Nottingham <no...@apache.org>]

Hi

I think David is right on this one. If we look at ConfigAdmin as an example.
The ConfigAdmin interface contains two interfaces (well it contains more,
but two of import to my example):

ConfigurationAdmin
ConfigurationListener

A ConfigAdmin implementation implements ConfigAdmin. In this example adding
a method to ConfigurationAdmin constitute a "compatible" change. i.e. a user
of the service does not care. However adding a method to
ConfigurationListener would constitute a major version change. This is
because ConfigurationAdmin is to be used by clients of the spec and
ConfigurationListener to be implemented by them.

It really relates whether the implementor of the interface is a "provider"
or a "user" of the package. I'm not sure this is well explained :(

How we "detect this" might be tough, but we have a good starting point. We
could look at the source for javadoc tags @userimplements or we could
provide annotations, or allow configuration to say "this is user
implementable stuff".

Alasdair

On 29 September 2011 14:30, Jeremy Hughes <hu...@apache.org> wrote:

> On 29 September 2011 12:25, David Bosschaert <da...@gmail.com>
> wrote:
> > On 29 September 2011 11:58, Jeremy Hughes <hu...@apache.org> wrote:
> [snip]
> >>
> >> I think it's on a package level, not a technology level.
> >>
> >> To quote the white paper (executive summary):
> >>
> >> "A package can contain an API. There are two types of clients for
> >> these API packages: API consumers and API
> >> implementation providers. A change in the second (minor) part of the
> >> version signals that the change is
> >> backward compatible with consumers of the API package but not with the
> >> providers of that API. That is,
> >> when the API package goes from version 1.5 to 1.6 it is no longer
> >> compatible with a provider of that API but
> >> consumers of that API are backward compatible with that API package."
> >>
> >> An implementer of BlueprintListener is an API implementation provider.
> >> A single class can be an API implementation provider of
> >> BlueprintListener while being an API consumer of other blueprint
> >> packages. I don't believe the whitepaper describes the subtlety you
> >> allude to. Have I missed something?
> >
> > And again, I may have missed something here too :) The situation that
> > I'm describing here is that *within* a single package (e.g. the
> > org.osgi.service.blueprint.container package to stay with our example)
> > one could be a consumer while still implementing an API provided by
> > that package.
> >
> > That's why when in our example when
> > org.osgi.service.blueprint.container.BlueprintContainer gets a new
> > method only the minor version of the package needs to be increased (as
> > consumers don't implement this interface) but when
> > org.osgi.service.blueprint.container.BlueprintListener gets a new
> > method the major version of the package needs to be increased as
> > consumers do implement this interface, but given they're a consumer
> > should be allowed to specify a version range like [1.0.0, 2.0.0).
>
> I see what you mean and the whitepaper discusses this scenario in the
> 4th para of p8:
>
> "An interesting problem for exporters is the policy applied to
> interfaces that are implemented by the consumers of the API. For
> example, in the OSGi framework, the Bundle Activator interface is not
> implemented by a framework provider but by consumers of the framework
> API: bundles. A change in such an interface will not be backward
> compatible with any consumers of the API and therefore requires a
> change in the major part of the version. API designers must therefore
> be acutely aware of the usage pattern of their interfaces and try to
> prevent making changes to interfaces that are implemented by the
> consumers of the API. Any change in an interface that is implemented
> by a consumer of the API breaks backward compatibility for all
> consumers."
>
> Oddly, this conflicts with the 2nd para of p8:
>
> "Tools will be able to detect syntactic violations of the semantic
> versioning by comparing a previous version and the new version."
>
> A tool cannot determine whether an interface in an exported package is
> being exported for consumers or for implementers. There's no standard
> way of doing so. Moreover, if there was, it wouldn't be enforceable at
> compile time without changes to the compiler. A tool doesn't have
> visibility to all the possible importers of the package. It therefore
> cannot say whether a package is being used by consumers or
> implementers ... or both!!
>
> IMHO the whitepaper attempts to protect consumers too vigorously. A
> better arrangement would be for the exporter to modify the minor or
> major version based on changes to the interface(s) in the package
> rather than what an importer might decide what to do with it. (since I
> already mentioned declaring what an importer can / cannot do with it
> is unenforceable). There's nothing wrong with consumers being mindful
> of what packages they import for interfaces they wish to implement and
> set their import version ranges appropriately.
>
> So:
>
> a) the white paper is in conflict with itself para 2 vs 4 on p8
> b) what is proposed in para 4 cannot be implemented by tools, so will
> be ignored by tools providers and will eventually fall by the wayside
>
> I guess now, I'm posting to the wrong list as this should be a
> discussion with the paper's authors ;-)
>
> >
> > Cheers,
> >
> > David
> >
>



-- 
Alasdair Nottingham
not@apache.org

Re: Semantic Versioning tool

[Jeremy Hughes <hu...@apache.org>]

On 29 September 2011 12:25, David Bosschaert <da...@gmail.com> wrote:
> On 29 September 2011 11:58, Jeremy Hughes <hu...@apache.org> wrote:
[snip]
>>
>> I think it's on a package level, not a technology level.
>>
>> To quote the white paper (executive summary):
>>
>> "A package can contain an API. There are two types of clients for
>> these API packages: API consumers and API
>> implementation providers. A change in the second (minor) part of the
>> version signals that the change is
>> backward compatible with consumers of the API package but not with the
>> providers of that API. That is,
>> when the API package goes from version 1.5 to 1.6 it is no longer
>> compatible with a provider of that API but
>> consumers of that API are backward compatible with that API package."
>>
>> An implementer of BlueprintListener is an API implementation provider.
>> A single class can be an API implementation provider of
>> BlueprintListener while being an API consumer of other blueprint
>> packages. I don't believe the whitepaper describes the subtlety you
>> allude to. Have I missed something?
>
> And again, I may have missed something here too :) The situation that
> I'm describing here is that *within* a single package (e.g. the
> org.osgi.service.blueprint.container package to stay with our example)
> one could be a consumer while still implementing an API provided by
> that package.
>
> That's why when in our example when
> org.osgi.service.blueprint.container.BlueprintContainer gets a new
> method only the minor version of the package needs to be increased (as
> consumers don't implement this interface) but when
> org.osgi.service.blueprint.container.BlueprintListener gets a new
> method the major version of the package needs to be increased as
> consumers do implement this interface, but given they're a consumer
> should be allowed to specify a version range like [1.0.0, 2.0.0).

I see what you mean and the whitepaper discusses this scenario in the
4th para of p8:

"An interesting problem for exporters is the policy applied to
interfaces that are implemented by the consumers of the API. For
example, in the OSGi framework, the Bundle Activator interface is not
implemented by a framework provider but by consumers of the framework
API: bundles. A change in such an interface will not be backward
compatible with any consumers of the API and therefore requires a
change in the major part of the version. API designers must therefore
be acutely aware of the usage pattern of their interfaces and try to
prevent making changes to interfaces that are implemented by the
consumers of the API. Any change in an interface that is implemented
by a consumer of the API breaks backward compatibility for all
consumers."

Oddly, this conflicts with the 2nd para of p8:

"Tools will be able to detect syntactic violations of the semantic
versioning by comparing a previous version and the new version."

A tool cannot determine whether an interface in an exported package is
being exported for consumers or for implementers. There's no standard
way of doing so. Moreover, if there was, it wouldn't be enforceable at
compile time without changes to the compiler. A tool doesn't have
visibility to all the possible importers of the package. It therefore
cannot say whether a package is being used by consumers or
implementers ... or both!!

IMHO the whitepaper attempts to protect consumers too vigorously. A
better arrangement would be for the exporter to modify the minor or
major version based on changes to the interface(s) in the package
rather than what an importer might decide what to do with it. (since I
already mentioned declaring what an importer can / cannot do with it
is unenforceable). There's nothing wrong with consumers being mindful
of what packages they import for interfaces they wish to implement and
set their import version ranges appropriately.

So:

a) the white paper is in conflict with itself para 2 vs 4 on p8
b) what is proposed in para 4 cannot be implemented by tools, so will
be ignored by tools providers and will eventually fall by the wayside

I guess now, I'm posting to the wrong list as this should be a
discussion with the paper's authors ;-)

>
> Cheers,
>
> David
>

Re: Semantic Versioning tool

[Emily Jiang <em...@googlemail.com>]

Hi David,

To clarify, this tool scans export package and bundle version not import
package, as we know the import package needs human intervention. This might
explain the confusions.

Thanks
Emily



On Thu, Sep 29, 2011 at 1:20 PM, Emily Jiang <em...@googlemail.com>wrote:

> I think this is a discussion regarding how to label a consumer or
> implementor For your example, the client is both a implementor and consumer.
> My take is that when you need to implement any interface you will be a
> implementor. Therefore, the client should limits to minor version changes.
> However, as far as package semenatic versioning is concerned, it should
> purly depend on the package owner not by the usage.
> Regards
> Emily
>
>
> On Thu, Sep 29, 2011 at 12:25 PM, David Bosschaert <
> david.bosschaert@gmail.com> wrote:
>
>> On 29 September 2011 11:58, Jeremy Hughes <hu...@apache.org> wrote:
>> > On 29 September 2011 11:43, David Bosschaert <
>> david.bosschaert@gmail.com> >> On 29 September 2011 11:32, Emily Jiang <
>> emijiang6@googlemail.com> wrote:
>> >>> On Thu, Sep 29, 2011 at 11:24 AM, David Bosschaert <
>> >>> david.bosschaert@gmail.com> wrote:
>> >>>
>> >>>> Hi Emily,
>> >>>>
>> >>>> I'm not sure that's sufficient... Just a small example.
>> >>>>
>> >>>> Let say your bundle provides an interface FooCallback that users of
>> >>>> your project need to implement to receive callbacks. If you add a
>> >>>> method x() to that interface, all of your consumers will stop to
>> >>>> compile. This should be a major version upgrade.
>> >>>>
>> >>>> In this case, according to semantic versioning white page, the
>> implementor
>> >>> limits its version range to a minor version changes e.g. [1.0.0,
>> 1.10). It
>> >>> should not tolerate any minor version changes. Any minor version
>> changes
>> >>> will not make into this client.
>> >>
>> >> I'm happy to be proven wrong but I think the definition of an
>> >> implementor is not as simple as you describe above.
>> >>
>> >> I think that, in the context of semantic versioning, an implementor is
>> >> considered to be someone who provides an implementation of a
>> >> technology. Like for instance Apache Aries is an implementor of the
>> >> Blueprint technology.
>> >
>> > I think it's on a package level, not a technology level.
>> >
>> > To quote the white paper (executive summary):
>> >
>> > "A package can contain an API. There are two types of clients for
>> > these API packages: API consumers and API
>> > implementation providers. A change in the second (minor) part of the
>> > version signals that the change is
>> > backward compatible with consumers of the API package but not with the
>> > providers of that API. That is,
>> > when the API package goes from version 1.5 to 1.6 it is no longer
>> > compatible with a provider of that API but
>> > consumers of that API are backward compatible with that API package."
>> >
>> > An implementer of BlueprintListener is an API implementation provider.
>> > A single class can be an API implementation provider of
>> > BlueprintListener while being an API consumer of other blueprint
>> > packages. I don't believe the whitepaper describes the subtlety you
>> > allude to. Have I missed something?
>>
>> And again, I may have missed something here too :) The situation that
>> I'm describing here is that *within* a single package (e.g. the
>> org.osgi.service.blueprint.container package to stay with our example)
>> one could be a consumer while still implementing an API provided by
>> that package.
>>
>> That's why when in our example when
>> org.osgi.service.blueprint.container.BlueprintContainer gets a new
>> method only the minor version of the package needs to be increased (as
>> consumers don't implement this interface) but when
>> org.osgi.service.blueprint.container.BlueprintListener gets a new
>> method the major version of the package needs to be increased as
>> consumers do implement this interface, but given they're a consumer
>> should be allowed to specify a version range like [1.0.0, 2.0.0).
>>
>> Cheers,
>>
>> David
>>
>
>
>
> --
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang@apache.org
>
>


-- 
Thanks
Emily
=================
Emily Jiang
ejiang@apache.org

Re: Semantic Versioning tool

[Emily Jiang <em...@googlemail.com>]

I think this is a discussion regarding how to label a consumer or
implementor For your example, the client is both a implementor and consumer.
My take is that when you need to implement any interface you will be a
implementor. Therefore, the client should limits to minor version changes.
However, as far as package semenatic versioning is concerned, it should
purly depend on the package owner not by the usage.
Regards
Emily

On Thu, Sep 29, 2011 at 12:25 PM, David Bosschaert <
david.bosschaert@gmail.com> wrote:

> On 29 September 2011 11:58, Jeremy Hughes <hu...@apache.org> wrote:
> > On 29 September 2011 11:43, David Bosschaert <da...@gmail.com>
> >> On 29 September 2011 11:32, Emily Jiang <em...@googlemail.com>
> wrote:
> >>> On Thu, Sep 29, 2011 at 11:24 AM, David Bosschaert <
> >>> david.bosschaert@gmail.com> wrote:
> >>>
> >>>> Hi Emily,
> >>>>
> >>>> I'm not sure that's sufficient... Just a small example.
> >>>>
> >>>> Let say your bundle provides an interface FooCallback that users of
> >>>> your project need to implement to receive callbacks. If you add a
> >>>> method x() to that interface, all of your consumers will stop to
> >>>> compile. This should be a major version upgrade.
> >>>>
> >>>> In this case, according to semantic versioning white page, the
> implementor
> >>> limits its version range to a minor version changes e.g. [1.0.0, 1.10).
> It
> >>> should not tolerate any minor version changes. Any minor version
> changes
> >>> will not make into this client.
> >>
> >> I'm happy to be proven wrong but I think the definition of an
> >> implementor is not as simple as you describe above.
> >>
> >> I think that, in the context of semantic versioning, an implementor is
> >> considered to be someone who provides an implementation of a
> >> technology. Like for instance Apache Aries is an implementor of the
> >> Blueprint technology.
> >
> > I think it's on a package level, not a technology level.
> >
> > To quote the white paper (executive summary):
> >
> > "A package can contain an API. There are two types of clients for
> > these API packages: API consumers and API
> > implementation providers. A change in the second (minor) part of the
> > version signals that the change is
> > backward compatible with consumers of the API package but not with the
> > providers of that API. That is,
> > when the API package goes from version 1.5 to 1.6 it is no longer
> > compatible with a provider of that API but
> > consumers of that API are backward compatible with that API package."
> >
> > An implementer of BlueprintListener is an API implementation provider.
> > A single class can be an API implementation provider of
> > BlueprintListener while being an API consumer of other blueprint
> > packages. I don't believe the whitepaper describes the subtlety you
> > allude to. Have I missed something?
>
> And again, I may have missed something here too :) The situation that
> I'm describing here is that *within* a single package (e.g. the
> org.osgi.service.blueprint.container package to stay with our example)
> one could be a consumer while still implementing an API provided by
> that package.
>
> That's why when in our example when
> org.osgi.service.blueprint.container.BlueprintContainer gets a new
> method only the minor version of the package needs to be increased (as
> consumers don't implement this interface) but when
> org.osgi.service.blueprint.container.BlueprintListener gets a new
> method the major version of the package needs to be increased as
> consumers do implement this interface, but given they're a consumer
> should be allowed to specify a version range like [1.0.0, 2.0.0).
>
> Cheers,
>
> David
>



-- 
Thanks
Emily
=================
Emily Jiang
ejiang@apache.org

Re: Semantic Versioning tool

[David Bosschaert <da...@gmail.com>]

On 29 September 2011 11:58, Jeremy Hughes <hu...@apache.org> wrote:
> On 29 September 2011 11:43, David Bosschaert <da...@gmail.com> >> On 29 September 2011 11:32, Emily Jiang <em...@googlemail.com> wrote:
>>> On Thu, Sep 29, 2011 at 11:24 AM, David Bosschaert <
>>> david.bosschaert@gmail.com> wrote:
>>>
>>>> Hi Emily,
>>>>
>>>> I'm not sure that's sufficient... Just a small example.
>>>>
>>>> Let say your bundle provides an interface FooCallback that users of
>>>> your project need to implement to receive callbacks. If you add a
>>>> method x() to that interface, all of your consumers will stop to
>>>> compile. This should be a major version upgrade.
>>>>
>>>> In this case, according to semantic versioning white page, the implementor
>>> limits its version range to a minor version changes e.g. [1.0.0, 1.10). It
>>> should not tolerate any minor version changes. Any minor version changes
>>> will not make into this client.
>>
>> I'm happy to be proven wrong but I think the definition of an
>> implementor is not as simple as you describe above.
>>
>> I think that, in the context of semantic versioning, an implementor is
>> considered to be someone who provides an implementation of a
>> technology. Like for instance Apache Aries is an implementor of the
>> Blueprint technology.
>
> I think it's on a package level, not a technology level.
>
> To quote the white paper (executive summary):
>
> "A package can contain an API. There are two types of clients for
> these API packages: API consumers and API
> implementation providers. A change in the second (minor) part of the
> version signals that the change is
> backward compatible with consumers of the API package but not with the
> providers of that API. That is,
> when the API package goes from version 1.5 to 1.6 it is no longer
> compatible with a provider of that API but
> consumers of that API are backward compatible with that API package."
>
> An implementer of BlueprintListener is an API implementation provider.
> A single class can be an API implementation provider of
> BlueprintListener while being an API consumer of other blueprint
> packages. I don't believe the whitepaper describes the subtlety you
> allude to. Have I missed something?

And again, I may have missed something here too :) The situation that
I'm describing here is that *within* a single package (e.g. the
org.osgi.service.blueprint.container package to stay with our example)
one could be a consumer while still implementing an API provided by
that package.

That's why when in our example when
org.osgi.service.blueprint.container.BlueprintContainer gets a new
method only the minor version of the package needs to be increased (as
consumers don't implement this interface) but when
org.osgi.service.blueprint.container.BlueprintListener gets a new
method the major version of the package needs to be increased as
consumers do implement this interface, but given they're a consumer
should be allowed to specify a version range like [1.0.0, 2.0.0).

Cheers,

David

Re: Semantic Versioning tool

[Jeremy Hughes <hu...@apache.org>]

Hi David, comments inline.

On 29 September 2011 11:43, David Bosschaert <da...@gmail.com> wrote:
> On 29 September 2011 11:32, Emily Jiang <em...@googlemail.com> wrote:
>> On Thu, Sep 29, 2011 at 11:24 AM, David Bosschaert <
>> david.bosschaert@gmail.com> wrote:
>>
>>> Hi Emily,
>>>
>>> I'm not sure that's sufficient... Just a small example.
>>>
>>> Let say your bundle provides an interface FooCallback that users of
>>> your project need to implement to receive callbacks. If you add a
>>> method x() to that interface, all of your consumers will stop to
>>> compile. This should be a major version upgrade.
>>>
>>> In this case, according to semantic versioning white page, the implementor
>> limits its version range to a minor version changes e.g. [1.0.0, 1.10). It
>> should not tolerate any minor version changes. Any minor version changes
>> will not make into this client.
>
> I'm happy to be proven wrong but I think the definition of an
> implementor is not as simple as you describe above.
>
> I think that, in the context of semantic versioning, an implementor is
> considered to be someone who provides an implementation of a
> technology. Like for instance Apache Aries is an implementor of the
> Blueprint technology.

I think it's on a package level, not a technology level.

To quote the white paper (executive summary):

"A package can contain an API. There are two types of clients for
these API packages: API consumers and API
implementation providers. A change in the second (minor) part of the
version signals that the change is
backward compatible with consumers of the API package but not with the
providers of that API. That is,
when the API package goes from version 1.5 to 1.6 it is no longer
compatible with a provider of that API but
consumers of that API are backward compatible with that API package."

An implementer of BlueprintListener is an API implementation provider.
A single class can be an API implementation provider of
BlueprintListener while being an API consumer of other blueprint
packages. I don't believe the whitepaper describes the subtlety you
allude to. Have I missed something?

>
> However, in some cases a user of a technology also needs to implement
> an interface in order to work with that technology. Just an example
> could be the BlueprintListener. You can implement that interface to
> interact with the Blueprint components but are not considered an
> implementor of the technology. In this case the an import of [1.0.0,
> 2.0.0) should work, given that you are logically speaking a consumer
> of the technology.
>
> Cheers,
>
> David
>

Re: Semantic Versioning tool

[David Bosschaert <da...@gmail.com>]

On 29 September 2011 11:32, Emily Jiang <em...@googlemail.com> wrote:
> On Thu, Sep 29, 2011 at 11:24 AM, David Bosschaert <
> david.bosschaert@gmail.com> wrote:
>
>> Hi Emily,
>>
>> I'm not sure that's sufficient... Just a small example.
>>
>> Let say your bundle provides an interface FooCallback that users of
>> your project need to implement to receive callbacks. If you add a
>> method x() to that interface, all of your consumers will stop to
>> compile. This should be a major version upgrade.
>>
>> In this case, according to semantic versioning white page, the implementor
> limits its version range to a minor version changes e.g. [1.0.0, 1.10). It
> should not tolerate any minor version changes. Any minor version changes
> will not make into this client.

I'm happy to be proven wrong but I think the definition of an
implementor is not as simple as you describe above.

I think that, in the context of semantic versioning, an implementor is
considered to be someone who provides an implementation of a
technology. Like for instance Apache Aries is an implementor of the
Blueprint technology.

However, in some cases a user of a technology also needs to implement
an interface in order to work with that technology. Just an example
could be the BlueprintListener. You can implement that interface to
interact with the Blueprint components but are not considered an
implementor of the technology. In this case the an import of [1.0.0,
2.0.0) should work, given that you are logically speaking a consumer
of the technology.

Cheers,

David

Re: Semantic Versioning tool

[Emily Jiang <em...@googlemail.com>]

On Thu, Sep 29, 2011 at 11:24 AM, David Bosschaert <
david.bosschaert@gmail.com> wrote:

> Hi Emily,
>
> I'm not sure that's sufficient... Just a small example.
>
> Let say your bundle provides an interface FooCallback that users of
> your project need to implement to receive callbacks. If you add a
> method x() to that interface, all of your consumers will stop to
> compile. This should be a major version upgrade.
>
> In this case, according to semantic versioning white page, the implementor
limits its version range to a minor version changes e.g. [1.0.0, 1.10). It
should not tolerate any minor version changes. Any minor version changes
will not make into this client.

> On the other hand if you have an interface Foo that users simply call
> (e.g. it might be provided by a service that's part of your project),
> then adding x() will be fine for users so in this case a minor version
> upgrade is needed.
>
> In this scenario, the client limits its version range to a major version
changes e.g. [1.0.0, 2.0.0). It should not tolerate any major version
changes. Any major version changes will not make into this client.

> I *think* that in most cases it a human will need to decide in which
> category an interface falls.
>
> In any case, I fully support this effort. We can have another
> discussion on the details when the subproject is there.
>
> Thank you:)


> Best regards,
>
> David
>
> On 29 September 2011 10:29, Emily Jiang <em...@googlemail.com> wrote:
> > Hi David,
> >
> > For an interface, the tool just finds out whether it has binary
> > compatibility changes or not. If yes, the major version will need to be
> > updated. If it has new methods etc (based on sementic versioning white
> > paper), its minor version needs to be increased. Its version should be
> > determined by the changes not by the different types of clients. As
> > mentioned by Valentin, its client or implementors can protect themselves
> by
> > using different version ranges.
> >
> > By the way, the tool is implemented based on the semantic version white
> > paper as per your email.
> >
> > Regards
> > Emily
> >
> > On Thu, Sep 29, 2011 at 9:05 AM, David Bosschaert <
> > david.bosschaert@gmail.com> wrote:
> >
> >> Hi Valentin,
> >>
> >> It's all in this doc:
> >> www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf
> >>
> >> Cheers,
> >>
> >> David
> >>
> >> On 29 September 2011 08:34, Valentin Mahrwald <vmahrwald@googlemail.com
> >
> >> wrote:
> >> > Hm, I thought the distinction between usage of the interface was a
> >> distinction made on the import side. So as for an interface I am using
> but
> >> not implementing I have a range of [a, a+1) and for one I am using
> through
> >> implementation, [a, a+0.1). In either case I would have thought the
> semantic
> >> versioning tool should suggest a+0.1 as the next version for adding a
> new
> >> method, so as to enable the user to make that choice.
> >> >
> >> > What am I missing?
> >> >
> >> > Regards,
> >> >
> >> > Valentin
> >> >
> >> > On 29 Sep 2011, at 08:28, David Bosschaert wrote:
> >> >
> >> >> Hi Emily,
> >> >>
> >> >> Yes, sounds great. Especially if this plugin can ultimately be
> >> >> integrated with maven and work alongside the maven-bundle-plugin that
> >> >> would be great.
> >> >>
> >> >> Regarding the semantic versioning, this relates to the role that a
> >> >> certain interface plays.
> >> >> If an interface is extended (e.g. with a new method) then there are
> >> >> two situations:
> >> >> * if it's an interface that is supposed to be *implemented* by end
> >> >> users then this is a major version increase. I think this is what you
> >> >> have right now.
> >> >> * however, if it's an interface that is supposed to be *used* by end
> >> >> users but implemented by the infrastructure (e.g. part of the
> >> >> 'project' you are comparing, which might span multiple bundles) then
> >> >> only a minor version increase is needed. In this case the interface
> is
> >> >> still binary compatible with users of it. It's just not compatible
> >> >> with implementors of it. Note that this only applies to a limited set
> >> >> of changes to an interface. E.g. removing a method is binary
> >> >> incompatible for everyone.
> >> >>
> >> >> I'm not sure whether its possible to automatically guess what the
> role
> >> >> of an interface is, so the tool needs to be configurable wrt to this.
> >> >> I would even suggest that the tool fails unless this information is
> >> >> available for all its public interfaces since guessing it wrong can
> >> >> have pretty bad consequences.
> >> >>
> >> >> Cheers,
> >> >>
> >> >> David
> >> >>
> >> >> On 28 September 2011 19:36, Alasdair Nottingham <no...@apache.org>
> wrote:
> >> >>> +1
> >> >>>
> >> >>> I think this would be a really good tool to have here. I'm happy to
> >> assist
> >> >>> with getting it integrated if you need anything.
> >> >>>
> >> >>> Thanks
> >> >>> Alasdair
> >> >>>
> >> >>> On 28 September 2011 17:17, Emily Jiang <em...@googlemail.com>
> >> wrote:
> >> >>>
> >> >>>> I use ASM and also have to load classes to access super classes:(.
> >> >>>>
> >> >>>> On Wed, Sep 28, 2011 at 5:10 PM, Timothy Ward <
> >> timothyjward@apache.org
> >> >>>>> wrote:
> >> >>>>
> >> >>>>>
> >> >>>>> Emily,
> >> >>>>>
> >> >>>>> Are you using ASM, or some other bytecode tool, to work out what
> has
> >> >>>>> changed, or do you have to load classes and use reflection to find
> >> out?
> >> >>>>>
> >> >>>>> Regards,
> >> >>>>>
> >> >>>>> Tim
> >> >>>>>
> >> >>>>>> Date: Wed, 28 Sep 2011 16:58:33 +0100
> >> >>>>>> Subject: Re: Semantic Versioning tool
> >> >>>>>> From: emijiang6@googlemail.com
> >> >>>>>> To: dev@aries.apache.org
> >> >>>>>>
> >> >>>>>> Hi David,
> >> >>>>>>
> >> >>>>>> It works by comparing the current binary with the baseline
> binary:
> >> >>>>>> 1. For each export package, it scans each non private class to
> see
> >> >>>>> whether
> >> >>>>>> there are binary incompatibility changes (according to Java
> >> >>>>> specificiation
> >> >>>>>> chapter 13 Binary Compability). If yes, a major version change is
> >> >>>> needed
> >> >>>>> for
> >> >>>>>> this pkg.
> >> >>>>>> 2. If there are not binary incompability changes, it will see
> >> whether
> >> >>>>> there
> >> >>>>>> are abstract class, methods or new xsd file added. If yes, the
> >> >>>> package's
> >> >>>>>> minor version needs to be increased.
> >> >>>>>> 3. It then determine the bundle version based on package versions
> >> >>>> changed
> >> >>>>>> according to semantic versioning white paper.
> >> >>>>>>
> >> >>>>>> The tool ignore micro version changes.
> >> >>>>>>
> >> >>>>>> I can contribute the tool as a project and then we can create a
> mvn
> >> >>>>> plugin
> >> >>>>>> from it or something even smarter.
> >> >>>>>>
> >> >>>>>> Regards,
> >> >>>>>> Emily
> >> >>>>>>
> >> >>>>>> On Wed, Sep 28, 2011 at 4:16 PM, David Bosschaert <
> >> >>>>>> david.bosschaert@gmail.com> wrote:
> >> >>>>>>
> >> >>>>>>> Very interesting, Emily. Would you be able to provide some
> >> >>>> information
> >> >>>>>>> regarding how it works?
> >> >>>>>>>
> >> >>>>>>> In any case I would welcome such an addition to Aries.
> >> >>>>>>>
> >> >>>>>>> Best regards,
> >> >>>>>>>
> >> >>>>>>> David
> >> >>>>>>>
> >> >>>>>>> On 28 September 2011 16:02, Emily Jiang <
> emijiang6@googlemail.com>
> >> >>>>> wrote:
> >> >>>>>>>> I have developed a semantic checking tool to check whether a
> >> >>>> bundle's
> >> >>>>>>>> version or the export package versions are correclty versioned
> >> >>>>> according
> >> >>>>>>> to
> >> >>>>>>>> OSGi semantic versioning whitepaper. I would like to contribute
> to
> >> >>>>> Apache
> >> >>>>>>>> Aries as subproject under a code name of 'llama' ( or a better
> >> >>>> name.
> >> >>>>> I am
> >> >>>>>>>> open to suggestions).
> >> >>>>>>>>
> >> >>>>>>>> Any thoughts or suggestions?
> >> >>>>>>>> --
> >> >>>>>>>> Thanks
> >> >>>>>>>> Emily
> >> >>>>>>>> =================
> >> >>>>>>>> Emily Jiang
> >> >>>>>>>> ejiang@apache.org
> >> >>>>>>>>
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> --
> >> >>>>>> Thanks
> >> >>>>>> Emily
> >> >>>>>> =================
> >> >>>>>> Emily Jiang
> >> >>>>>> ejiang@apache.org
> >> >>>>>
> >> >>>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> --
> >> >>>> Thanks
> >> >>>> Emily
> >> >>>> =================
> >> >>>> Emily Jiang
> >> >>>> ejiang@apache.org
> >> >>>>
> >> >>>
> >> >>>
> >> >>>
> >> >>> --
> >> >>> Alasdair Nottingham
> >> >>> not@apache.org
> >> >>>
> >> >
> >> >
> >>
> >
> >
> >
> > --
> > Thanks
> > Emily
> > =================
> > Emily Jiang
> > ejiang@apache.org
> >
>



-- 
Thanks
Emily
=================
Emily Jiang
ejiang@apache.org

Re: Semantic Versioning tool

[David Bosschaert <da...@gmail.com>]

Hi Emily,

I'm not sure that's sufficient... Just a small example.

Let say your bundle provides an interface FooCallback that users of
your project need to implement to receive callbacks. If you add a
method x() to that interface, all of your consumers will stop to
compile. This should be a major version upgrade.

On the other hand if you have an interface Foo that users simply call
(e.g. it might be provided by a service that's part of your project),
then adding x() will be fine for users so in this case a minor version
upgrade is needed.

I *think* that in most cases it a human will need to decide in which
category an interface falls.

In any case, I fully support this effort. We can have another
discussion on the details when the subproject is there.

Best regards,

David

On 29 September 2011 10:29, Emily Jiang <em...@googlemail.com> wrote:
> Hi David,
>
> For an interface, the tool just finds out whether it has binary
> compatibility changes or not. If yes, the major version will need to be
> updated. If it has new methods etc (based on sementic versioning white
> paper), its minor version needs to be increased. Its version should be
> determined by the changes not by the different types of clients. As
> mentioned by Valentin, its client or implementors can protect themselves by
> using different version ranges.
>
> By the way, the tool is implemented based on the semantic version white
> paper as per your email.
>
> Regards
> Emily
>
> On Thu, Sep 29, 2011 at 9:05 AM, David Bosschaert <
> david.bosschaert@gmail.com> wrote:
>
>> Hi Valentin,
>>
>> It's all in this doc:
>> www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf
>>
>> Cheers,
>>
>> David
>>
>> On 29 September 2011 08:34, Valentin Mahrwald <vm...@googlemail.com>
>> wrote:
>> > Hm, I thought the distinction between usage of the interface was a
>> distinction made on the import side. So as for an interface I am using but
>> not implementing I have a range of [a, a+1) and for one I am using through
>> implementation, [a, a+0.1). In either case I would have thought the semantic
>> versioning tool should suggest a+0.1 as the next version for adding a new
>> method, so as to enable the user to make that choice.
>> >
>> > What am I missing?
>> >
>> > Regards,
>> >
>> > Valentin
>> >
>> > On 29 Sep 2011, at 08:28, David Bosschaert wrote:
>> >
>> >> Hi Emily,
>> >>
>> >> Yes, sounds great. Especially if this plugin can ultimately be
>> >> integrated with maven and work alongside the maven-bundle-plugin that
>> >> would be great.
>> >>
>> >> Regarding the semantic versioning, this relates to the role that a
>> >> certain interface plays.
>> >> If an interface is extended (e.g. with a new method) then there are
>> >> two situations:
>> >> * if it's an interface that is supposed to be *implemented* by end
>> >> users then this is a major version increase. I think this is what you
>> >> have right now.
>> >> * however, if it's an interface that is supposed to be *used* by end
>> >> users but implemented by the infrastructure (e.g. part of the
>> >> 'project' you are comparing, which might span multiple bundles) then
>> >> only a minor version increase is needed. In this case the interface is
>> >> still binary compatible with users of it. It's just not compatible
>> >> with implementors of it. Note that this only applies to a limited set
>> >> of changes to an interface. E.g. removing a method is binary
>> >> incompatible for everyone.
>> >>
>> >> I'm not sure whether its possible to automatically guess what the role
>> >> of an interface is, so the tool needs to be configurable wrt to this.
>> >> I would even suggest that the tool fails unless this information is
>> >> available for all its public interfaces since guessing it wrong can
>> >> have pretty bad consequences.
>> >>
>> >> Cheers,
>> >>
>> >> David
>> >>
>> >> On 28 September 2011 19:36, Alasdair Nottingham <no...@apache.org> wrote:
>> >>> +1
>> >>>
>> >>> I think this would be a really good tool to have here. I'm happy to
>> assist
>> >>> with getting it integrated if you need anything.
>> >>>
>> >>> Thanks
>> >>> Alasdair
>> >>>
>> >>> On 28 September 2011 17:17, Emily Jiang <em...@googlemail.com>
>> wrote:
>> >>>
>> >>>> I use ASM and also have to load classes to access super classes:(.
>> >>>>
>> >>>> On Wed, Sep 28, 2011 at 5:10 PM, Timothy Ward <
>> timothyjward@apache.org
>> >>>>> wrote:
>> >>>>
>> >>>>>
>> >>>>> Emily,
>> >>>>>
>> >>>>> Are you using ASM, or some other bytecode tool, to work out what has
>> >>>>> changed, or do you have to load classes and use reflection to find
>> out?
>> >>>>>
>> >>>>> Regards,
>> >>>>>
>> >>>>> Tim
>> >>>>>
>> >>>>>> Date: Wed, 28 Sep 2011 16:58:33 +0100
>> >>>>>> Subject: Re: Semantic Versioning tool
>> >>>>>> From: emijiang6@googlemail.com
>> >>>>>> To: dev@aries.apache.org
>> >>>>>>
>> >>>>>> Hi David,
>> >>>>>>
>> >>>>>> It works by comparing the current binary with the baseline binary:
>> >>>>>> 1. For each export package, it scans each non private class to see
>> >>>>> whether
>> >>>>>> there are binary incompatibility changes (according to Java
>> >>>>> specificiation
>> >>>>>> chapter 13 Binary Compability). If yes, a major version change is
>> >>>> needed
>> >>>>> for
>> >>>>>> this pkg.
>> >>>>>> 2. If there are not binary incompability changes, it will see
>> whether
>> >>>>> there
>> >>>>>> are abstract class, methods or new xsd file added. If yes, the
>> >>>> package's
>> >>>>>> minor version needs to be increased.
>> >>>>>> 3. It then determine the bundle version based on package versions
>> >>>> changed
>> >>>>>> according to semantic versioning white paper.
>> >>>>>>
>> >>>>>> The tool ignore micro version changes.
>> >>>>>>
>> >>>>>> I can contribute the tool as a project and then we can create a mvn
>> >>>>> plugin
>> >>>>>> from it or something even smarter.
>> >>>>>>
>> >>>>>> Regards,
>> >>>>>> Emily
>> >>>>>>
>> >>>>>> On Wed, Sep 28, 2011 at 4:16 PM, David Bosschaert <
>> >>>>>> david.bosschaert@gmail.com> wrote:
>> >>>>>>
>> >>>>>>> Very interesting, Emily. Would you be able to provide some
>> >>>> information
>> >>>>>>> regarding how it works?
>> >>>>>>>
>> >>>>>>> In any case I would welcome such an addition to Aries.
>> >>>>>>>
>> >>>>>>> Best regards,
>> >>>>>>>
>> >>>>>>> David
>> >>>>>>>
>> >>>>>>> On 28 September 2011 16:02, Emily Jiang <em...@googlemail.com>
>> >>>>> wrote:
>> >>>>>>>> I have developed a semantic checking tool to check whether a
>> >>>> bundle's
>> >>>>>>>> version or the export package versions are correclty versioned
>> >>>>> according
>> >>>>>>> to
>> >>>>>>>> OSGi semantic versioning whitepaper. I would like to contribute to
>> >>>>> Apache
>> >>>>>>>> Aries as subproject under a code name of 'llama' ( or a better
>> >>>> name.
>> >>>>> I am
>> >>>>>>>> open to suggestions).
>> >>>>>>>>
>> >>>>>>>> Any thoughts or suggestions?
>> >>>>>>>> --
>> >>>>>>>> Thanks
>> >>>>>>>> Emily
>> >>>>>>>> =================
>> >>>>>>>> Emily Jiang
>> >>>>>>>> ejiang@apache.org
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> --
>> >>>>>> Thanks
>> >>>>>> Emily
>> >>>>>> =================
>> >>>>>> Emily Jiang
>> >>>>>> ejiang@apache.org
>> >>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Thanks
>> >>>> Emily
>> >>>> =================
>> >>>> Emily Jiang
>> >>>> ejiang@apache.org
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Alasdair Nottingham
>> >>> not@apache.org
>> >>>
>> >
>> >
>>
>
>
>
> --
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang@apache.org
>

Re: Semantic Versioning tool

[Emily Jiang <em...@googlemail.com>]

Thanks all for your support:). I will start creating a subproject for it.

Regards
Emily

On Thu, Sep 29, 2011 at 10:50 AM, Graham Charters <gc...@gmail.com>wrote:

> +1
>
> Semantic versioning is a very difficult concept to get right - as the
> discussion on this thread are demonstrating ;)  If we can identify
> when things are clearly wrong and make recommendations, then that
> would be a huge step forward.
>
> It would be nice if we could have a core capability that's agnostic of
> environment (i.e. whether it is used in Maven, Ant, Eclipse, etc.) and
> then use that to enable checking in those environments.  I'd be happy
> to help with the Maven integration...time permitting :-S
>
> Graham.
>
> On 29 September 2011 10:29, Emily Jiang <em...@googlemail.com> wrote:
> > Hi David,
> >
> > For an interface, the tool just finds out whether it has binary
> > compatibility changes or not. If yes, the major version will need to be
> > updated. If it has new methods etc (based on sementic versioning white
> > paper), its minor version needs to be increased. Its version should be
> > determined by the changes not by the different types of clients. As
> > mentioned by Valentin, its client or implementors can protect themselves
> by
> > using different version ranges.
> >
> > By the way, the tool is implemented based on the semantic version white
> > paper as per your email.
> >
> > Regards
> > Emily
> >
> > On Thu, Sep 29, 2011 at 9:05 AM, David Bosschaert <
> > david.bosschaert@gmail.com> wrote:
> >
> >> Hi Valentin,
> >>
> >> It's all in this doc:
> >> www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf
> >>
> >> Cheers,
> >>
> >> David
> >>
> >> On 29 September 2011 08:34, Valentin Mahrwald <vmahrwald@googlemail.com
> >
> >> wrote:
> >> > Hm, I thought the distinction between usage of the interface was a
> >> distinction made on the import side. So as for an interface I am using
> but
> >> not implementing I have a range of [a, a+1) and for one I am using
> through
> >> implementation, [a, a+0.1). In either case I would have thought the
> semantic
> >> versioning tool should suggest a+0.1 as the next version for adding a
> new
> >> method, so as to enable the user to make that choice.
> >> >
> >> > What am I missing?
> >> >
> >> > Regards,
> >> >
> >> > Valentin
> >> >
> >> > On 29 Sep 2011, at 08:28, David Bosschaert wrote:
> >> >
> >> >> Hi Emily,
> >> >>
> >> >> Yes, sounds great. Especially if this plugin can ultimately be
> >> >> integrated with maven and work alongside the maven-bundle-plugin that
> >> >> would be great.
> >> >>
> >> >> Regarding the semantic versioning, this relates to the role that a
> >> >> certain interface plays.
> >> >> If an interface is extended (e.g. with a new method) then there are
> >> >> two situations:
> >> >> * if it's an interface that is supposed to be *implemented* by end
> >> >> users then this is a major version increase. I think this is what you
> >> >> have right now.
> >> >> * however, if it's an interface that is supposed to be *used* by end
> >> >> users but implemented by the infrastructure (e.g. part of the
> >> >> 'project' you are comparing, which might span multiple bundles) then
> >> >> only a minor version increase is needed. In this case the interface
> is
> >> >> still binary compatible with users of it. It's just not compatible
> >> >> with implementors of it. Note that this only applies to a limited set
> >> >> of changes to an interface. E.g. removing a method is binary
> >> >> incompatible for everyone.
> >> >>
> >> >> I'm not sure whether its possible to automatically guess what the
> role
> >> >> of an interface is, so the tool needs to be configurable wrt to this.
> >> >> I would even suggest that the tool fails unless this information is
> >> >> available for all its public interfaces since guessing it wrong can
> >> >> have pretty bad consequences.
> >> >>
> >> >> Cheers,
> >> >>
> >> >> David
> >> >>
> >> >> On 28 September 2011 19:36, Alasdair Nottingham <no...@apache.org>
> wrote:
> >> >>> +1
> >> >>>
> >> >>> I think this would be a really good tool to have here. I'm happy to
> >> assist
> >> >>> with getting it integrated if you need anything.
> >> >>>
> >> >>> Thanks
> >> >>> Alasdair
> >> >>>
> >> >>> On 28 September 2011 17:17, Emily Jiang <em...@googlemail.com>
> >> wrote:
> >> >>>
> >> >>>> I use ASM and also have to load classes to access super classes:(.
> >> >>>>
> >> >>>> On Wed, Sep 28, 2011 at 5:10 PM, Timothy Ward <
> >> timothyjward@apache.org
> >> >>>>> wrote:
> >> >>>>
> >> >>>>>
> >> >>>>> Emily,
> >> >>>>>
> >> >>>>> Are you using ASM, or some other bytecode tool, to work out what
> has
> >> >>>>> changed, or do you have to load classes and use reflection to find
> >> out?
> >> >>>>>
> >> >>>>> Regards,
> >> >>>>>
> >> >>>>> Tim
> >> >>>>>
> >> >>>>>> Date: Wed, 28 Sep 2011 16:58:33 +0100
> >> >>>>>> Subject: Re: Semantic Versioning tool
> >> >>>>>> From: emijiang6@googlemail.com
> >> >>>>>> To: dev@aries.apache.org
> >> >>>>>>
> >> >>>>>> Hi David,
> >> >>>>>>
> >> >>>>>> It works by comparing the current binary with the baseline
> binary:
> >> >>>>>> 1. For each export package, it scans each non private class to
> see
> >> >>>>> whether
> >> >>>>>> there are binary incompatibility changes (according to Java
> >> >>>>> specificiation
> >> >>>>>> chapter 13 Binary Compability). If yes, a major version change is
> >> >>>> needed
> >> >>>>> for
> >> >>>>>> this pkg.
> >> >>>>>> 2. If there are not binary incompability changes, it will see
> >> whether
> >> >>>>> there
> >> >>>>>> are abstract class, methods or new xsd file added. If yes, the
> >> >>>> package's
> >> >>>>>> minor version needs to be increased.
> >> >>>>>> 3. It then determine the bundle version based on package versions
> >> >>>> changed
> >> >>>>>> according to semantic versioning white paper.
> >> >>>>>>
> >> >>>>>> The tool ignore micro version changes.
> >> >>>>>>
> >> >>>>>> I can contribute the tool as a project and then we can create a
> mvn
> >> >>>>> plugin
> >> >>>>>> from it or something even smarter.
> >> >>>>>>
> >> >>>>>> Regards,
> >> >>>>>> Emily
> >> >>>>>>
> >> >>>>>> On Wed, Sep 28, 2011 at 4:16 PM, David Bosschaert <
> >> >>>>>> david.bosschaert@gmail.com> wrote:
> >> >>>>>>
> >> >>>>>>> Very interesting, Emily. Would you be able to provide some
> >> >>>> information
> >> >>>>>>> regarding how it works?
> >> >>>>>>>
> >> >>>>>>> In any case I would welcome such an addition to Aries.
> >> >>>>>>>
> >> >>>>>>> Best regards,
> >> >>>>>>>
> >> >>>>>>> David
> >> >>>>>>>
> >> >>>>>>> On 28 September 2011 16:02, Emily Jiang <
> emijiang6@googlemail.com>
> >> >>>>> wrote:
> >> >>>>>>>> I have developed a semantic checking tool to check whether a
> >> >>>> bundle's
> >> >>>>>>>> version or the export package versions are correclty versioned
> >> >>>>> according
> >> >>>>>>> to
> >> >>>>>>>> OSGi semantic versioning whitepaper. I would like to contribute
> to
> >> >>>>> Apache
> >> >>>>>>>> Aries as subproject under a code name of 'llama' ( or a better
> >> >>>> name.
> >> >>>>> I am
> >> >>>>>>>> open to suggestions).
> >> >>>>>>>>
> >> >>>>>>>> Any thoughts or suggestions?
> >> >>>>>>>> --
> >> >>>>>>>> Thanks
> >> >>>>>>>> Emily
> >> >>>>>>>> =================
> >> >>>>>>>> Emily Jiang
> >> >>>>>>>> ejiang@apache.org
> >> >>>>>>>>
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> --
> >> >>>>>> Thanks
> >> >>>>>> Emily
> >> >>>>>> =================
> >> >>>>>> Emily Jiang
> >> >>>>>> ejiang@apache.org
> >> >>>>>
> >> >>>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> --
> >> >>>> Thanks
> >> >>>> Emily
> >> >>>> =================
> >> >>>> Emily Jiang
> >> >>>> ejiang@apache.org
> >> >>>>
> >> >>>
> >> >>>
> >> >>>
> >> >>> --
> >> >>> Alasdair Nottingham
> >> >>> not@apache.org
> >> >>>
> >> >
> >> >
> >>
> >
> >
> >
> > --
> > Thanks
> > Emily
> > =================
> > Emily Jiang
> > ejiang@apache.org
> >
>



-- 
Thanks
Emily
=================
Emily Jiang
ejiang@apache.org

Re: Semantic Versioning tool

[Graham Charters <gc...@gmail.com>]

+1

Semantic versioning is a very difficult concept to get right - as the
discussion on this thread are demonstrating ;)  If we can identify
when things are clearly wrong and make recommendations, then that
would be a huge step forward.

It would be nice if we could have a core capability that's agnostic of
environment (i.e. whether it is used in Maven, Ant, Eclipse, etc.) and
then use that to enable checking in those environments.  I'd be happy
to help with the Maven integration...time permitting :-S

Graham.

On 29 September 2011 10:29, Emily Jiang <em...@googlemail.com> wrote:
> Hi David,
>
> For an interface, the tool just finds out whether it has binary
> compatibility changes or not. If yes, the major version will need to be
> updated. If it has new methods etc (based on sementic versioning white
> paper), its minor version needs to be increased. Its version should be
> determined by the changes not by the different types of clients. As
> mentioned by Valentin, its client or implementors can protect themselves by
> using different version ranges.
>
> By the way, the tool is implemented based on the semantic version white
> paper as per your email.
>
> Regards
> Emily
>
> On Thu, Sep 29, 2011 at 9:05 AM, David Bosschaert <
> david.bosschaert@gmail.com> wrote:
>
>> Hi Valentin,
>>
>> It's all in this doc:
>> www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf
>>
>> Cheers,
>>
>> David
>>
>> On 29 September 2011 08:34, Valentin Mahrwald <vm...@googlemail.com>
>> wrote:
>> > Hm, I thought the distinction between usage of the interface was a
>> distinction made on the import side. So as for an interface I am using but
>> not implementing I have a range of [a, a+1) and for one I am using through
>> implementation, [a, a+0.1). In either case I would have thought the semantic
>> versioning tool should suggest a+0.1 as the next version for adding a new
>> method, so as to enable the user to make that choice.
>> >
>> > What am I missing?
>> >
>> > Regards,
>> >
>> > Valentin
>> >
>> > On 29 Sep 2011, at 08:28, David Bosschaert wrote:
>> >
>> >> Hi Emily,
>> >>
>> >> Yes, sounds great. Especially if this plugin can ultimately be
>> >> integrated with maven and work alongside the maven-bundle-plugin that
>> >> would be great.
>> >>
>> >> Regarding the semantic versioning, this relates to the role that a
>> >> certain interface plays.
>> >> If an interface is extended (e.g. with a new method) then there are
>> >> two situations:
>> >> * if it's an interface that is supposed to be *implemented* by end
>> >> users then this is a major version increase. I think this is what you
>> >> have right now.
>> >> * however, if it's an interface that is supposed to be *used* by end
>> >> users but implemented by the infrastructure (e.g. part of the
>> >> 'project' you are comparing, which might span multiple bundles) then
>> >> only a minor version increase is needed. In this case the interface is
>> >> still binary compatible with users of it. It's just not compatible
>> >> with implementors of it. Note that this only applies to a limited set
>> >> of changes to an interface. E.g. removing a method is binary
>> >> incompatible for everyone.
>> >>
>> >> I'm not sure whether its possible to automatically guess what the role
>> >> of an interface is, so the tool needs to be configurable wrt to this.
>> >> I would even suggest that the tool fails unless this information is
>> >> available for all its public interfaces since guessing it wrong can
>> >> have pretty bad consequences.
>> >>
>> >> Cheers,
>> >>
>> >> David
>> >>
>> >> On 28 September 2011 19:36, Alasdair Nottingham <no...@apache.org> wrote:
>> >>> +1
>> >>>
>> >>> I think this would be a really good tool to have here. I'm happy to
>> assist
>> >>> with getting it integrated if you need anything.
>> >>>
>> >>> Thanks
>> >>> Alasdair
>> >>>
>> >>> On 28 September 2011 17:17, Emily Jiang <em...@googlemail.com>
>> wrote:
>> >>>
>> >>>> I use ASM and also have to load classes to access super classes:(.
>> >>>>
>> >>>> On Wed, Sep 28, 2011 at 5:10 PM, Timothy Ward <
>> timothyjward@apache.org
>> >>>>> wrote:
>> >>>>
>> >>>>>
>> >>>>> Emily,
>> >>>>>
>> >>>>> Are you using ASM, or some other bytecode tool, to work out what has
>> >>>>> changed, or do you have to load classes and use reflection to find
>> out?
>> >>>>>
>> >>>>> Regards,
>> >>>>>
>> >>>>> Tim
>> >>>>>
>> >>>>>> Date: Wed, 28 Sep 2011 16:58:33 +0100
>> >>>>>> Subject: Re: Semantic Versioning tool
>> >>>>>> From: emijiang6@googlemail.com
>> >>>>>> To: dev@aries.apache.org
>> >>>>>>
>> >>>>>> Hi David,
>> >>>>>>
>> >>>>>> It works by comparing the current binary with the baseline binary:
>> >>>>>> 1. For each export package, it scans each non private class to see
>> >>>>> whether
>> >>>>>> there are binary incompatibility changes (according to Java
>> >>>>> specificiation
>> >>>>>> chapter 13 Binary Compability). If yes, a major version change is
>> >>>> needed
>> >>>>> for
>> >>>>>> this pkg.
>> >>>>>> 2. If there are not binary incompability changes, it will see
>> whether
>> >>>>> there
>> >>>>>> are abstract class, methods or new xsd file added. If yes, the
>> >>>> package's
>> >>>>>> minor version needs to be increased.
>> >>>>>> 3. It then determine the bundle version based on package versions
>> >>>> changed
>> >>>>>> according to semantic versioning white paper.
>> >>>>>>
>> >>>>>> The tool ignore micro version changes.
>> >>>>>>
>> >>>>>> I can contribute the tool as a project and then we can create a mvn
>> >>>>> plugin
>> >>>>>> from it or something even smarter.
>> >>>>>>
>> >>>>>> Regards,
>> >>>>>> Emily
>> >>>>>>
>> >>>>>> On Wed, Sep 28, 2011 at 4:16 PM, David Bosschaert <
>> >>>>>> david.bosschaert@gmail.com> wrote:
>> >>>>>>
>> >>>>>>> Very interesting, Emily. Would you be able to provide some
>> >>>> information
>> >>>>>>> regarding how it works?
>> >>>>>>>
>> >>>>>>> In any case I would welcome such an addition to Aries.
>> >>>>>>>
>> >>>>>>> Best regards,
>> >>>>>>>
>> >>>>>>> David
>> >>>>>>>
>> >>>>>>> On 28 September 2011 16:02, Emily Jiang <em...@googlemail.com>
>> >>>>> wrote:
>> >>>>>>>> I have developed a semantic checking tool to check whether a
>> >>>> bundle's
>> >>>>>>>> version or the export package versions are correclty versioned
>> >>>>> according
>> >>>>>>> to
>> >>>>>>>> OSGi semantic versioning whitepaper. I would like to contribute to
>> >>>>> Apache
>> >>>>>>>> Aries as subproject under a code name of 'llama' ( or a better
>> >>>> name.
>> >>>>> I am
>> >>>>>>>> open to suggestions).
>> >>>>>>>>
>> >>>>>>>> Any thoughts or suggestions?
>> >>>>>>>> --
>> >>>>>>>> Thanks
>> >>>>>>>> Emily
>> >>>>>>>> =================
>> >>>>>>>> Emily Jiang
>> >>>>>>>> ejiang@apache.org
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> --
>> >>>>>> Thanks
>> >>>>>> Emily
>> >>>>>> =================
>> >>>>>> Emily Jiang
>> >>>>>> ejiang@apache.org
>> >>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Thanks
>> >>>> Emily
>> >>>> =================
>> >>>> Emily Jiang
>> >>>> ejiang@apache.org
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Alasdair Nottingham
>> >>> not@apache.org
>> >>>
>> >
>> >
>>
>
>
>
> --
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang@apache.org
>

Re: Semantic Versioning tool

[Emily Jiang <em...@googlemail.com>]

Hi David,

For an interface, the tool just finds out whether it has binary
compatibility changes or not. If yes, the major version will need to be
updated. If it has new methods etc (based on sementic versioning white
paper), its minor version needs to be increased. Its version should be
determined by the changes not by the different types of clients. As
mentioned by Valentin, its client or implementors can protect themselves by
using different version ranges.

By the way, the tool is implemented based on the semantic version white
paper as per your email.

Regards
Emily

On Thu, Sep 29, 2011 at 9:05 AM, David Bosschaert <
david.bosschaert@gmail.com> wrote:

> Hi Valentin,
>
> It's all in this doc:
> www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf
>
> Cheers,
>
> David
>
> On 29 September 2011 08:34, Valentin Mahrwald <vm...@googlemail.com>
> wrote:
> > Hm, I thought the distinction between usage of the interface was a
> distinction made on the import side. So as for an interface I am using but
> not implementing I have a range of [a, a+1) and for one I am using through
> implementation, [a, a+0.1). In either case I would have thought the semantic
> versioning tool should suggest a+0.1 as the next version for adding a new
> method, so as to enable the user to make that choice.
> >
> > What am I missing?
> >
> > Regards,
> >
> > Valentin
> >
> > On 29 Sep 2011, at 08:28, David Bosschaert wrote:
> >
> >> Hi Emily,
> >>
> >> Yes, sounds great. Especially if this plugin can ultimately be
> >> integrated with maven and work alongside the maven-bundle-plugin that
> >> would be great.
> >>
> >> Regarding the semantic versioning, this relates to the role that a
> >> certain interface plays.
> >> If an interface is extended (e.g. with a new method) then there are
> >> two situations:
> >> * if it's an interface that is supposed to be *implemented* by end
> >> users then this is a major version increase. I think this is what you
> >> have right now.
> >> * however, if it's an interface that is supposed to be *used* by end
> >> users but implemented by the infrastructure (e.g. part of the
> >> 'project' you are comparing, which might span multiple bundles) then
> >> only a minor version increase is needed. In this case the interface is
> >> still binary compatible with users of it. It's just not compatible
> >> with implementors of it. Note that this only applies to a limited set
> >> of changes to an interface. E.g. removing a method is binary
> >> incompatible for everyone.
> >>
> >> I'm not sure whether its possible to automatically guess what the role
> >> of an interface is, so the tool needs to be configurable wrt to this.
> >> I would even suggest that the tool fails unless this information is
> >> available for all its public interfaces since guessing it wrong can
> >> have pretty bad consequences.
> >>
> >> Cheers,
> >>
> >> David
> >>
> >> On 28 September 2011 19:36, Alasdair Nottingham <no...@apache.org> wrote:
> >>> +1
> >>>
> >>> I think this would be a really good tool to have here. I'm happy to
> assist
> >>> with getting it integrated if you need anything.
> >>>
> >>> Thanks
> >>> Alasdair
> >>>
> >>> On 28 September 2011 17:17, Emily Jiang <em...@googlemail.com>
> wrote:
> >>>
> >>>> I use ASM and also have to load classes to access super classes:(.
> >>>>
> >>>> On Wed, Sep 28, 2011 at 5:10 PM, Timothy Ward <
> timothyjward@apache.org
> >>>>> wrote:
> >>>>
> >>>>>
> >>>>> Emily,
> >>>>>
> >>>>> Are you using ASM, or some other bytecode tool, to work out what has
> >>>>> changed, or do you have to load classes and use reflection to find
> out?
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> Tim
> >>>>>
> >>>>>> Date: Wed, 28 Sep 2011 16:58:33 +0100
> >>>>>> Subject: Re: Semantic Versioning tool
> >>>>>> From: emijiang6@googlemail.com
> >>>>>> To: dev@aries.apache.org
> >>>>>>
> >>>>>> Hi David,
> >>>>>>
> >>>>>> It works by comparing the current binary with the baseline binary:
> >>>>>> 1. For each export package, it scans each non private class to see
> >>>>> whether
> >>>>>> there are binary incompatibility changes (according to Java
> >>>>> specificiation
> >>>>>> chapter 13 Binary Compability). If yes, a major version change is
> >>>> needed
> >>>>> for
> >>>>>> this pkg.
> >>>>>> 2. If there are not binary incompability changes, it will see
> whether
> >>>>> there
> >>>>>> are abstract class, methods or new xsd file added. If yes, the
> >>>> package's
> >>>>>> minor version needs to be increased.
> >>>>>> 3. It then determine the bundle version based on package versions
> >>>> changed
> >>>>>> according to semantic versioning white paper.
> >>>>>>
> >>>>>> The tool ignore micro version changes.
> >>>>>>
> >>>>>> I can contribute the tool as a project and then we can create a mvn
> >>>>> plugin
> >>>>>> from it or something even smarter.
> >>>>>>
> >>>>>> Regards,
> >>>>>> Emily
> >>>>>>
> >>>>>> On Wed, Sep 28, 2011 at 4:16 PM, David Bosschaert <
> >>>>>> david.bosschaert@gmail.com> wrote:
> >>>>>>
> >>>>>>> Very interesting, Emily. Would you be able to provide some
> >>>> information
> >>>>>>> regarding how it works?
> >>>>>>>
> >>>>>>> In any case I would welcome such an addition to Aries.
> >>>>>>>
> >>>>>>> Best regards,
> >>>>>>>
> >>>>>>> David
> >>>>>>>
> >>>>>>> On 28 September 2011 16:02, Emily Jiang <em...@googlemail.com>
> >>>>> wrote:
> >>>>>>>> I have developed a semantic checking tool to check whether a
> >>>> bundle's
> >>>>>>>> version or the export package versions are correclty versioned
> >>>>> according
> >>>>>>> to
> >>>>>>>> OSGi semantic versioning whitepaper. I would like to contribute to
> >>>>> Apache
> >>>>>>>> Aries as subproject under a code name of 'llama' ( or a better
> >>>> name.
> >>>>> I am
> >>>>>>>> open to suggestions).
> >>>>>>>>
> >>>>>>>> Any thoughts or suggestions?
> >>>>>>>> --
> >>>>>>>> Thanks
> >>>>>>>> Emily
> >>>>>>>> =================
> >>>>>>>> Emily Jiang
> >>>>>>>> ejiang@apache.org
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Thanks
> >>>>>> Emily
> >>>>>> =================
> >>>>>> Emily Jiang
> >>>>>> ejiang@apache.org
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Thanks
> >>>> Emily
> >>>> =================
> >>>> Emily Jiang
> >>>> ejiang@apache.org
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Alasdair Nottingham
> >>> not@apache.org
> >>>
> >
> >
>



-- 
Thanks
Emily
=================
Emily Jiang
ejiang@apache.org

Re: Semantic Versioning tool

[David Bosschaert <da...@gmail.com>]

Hi Valentin,

It's all in this doc:
www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf

Cheers,

David

On 29 September 2011 08:34, Valentin Mahrwald <vm...@googlemail.com> wrote:
> Hm, I thought the distinction between usage of the interface was a distinction made on the import side. So as for an interface I am using but not implementing I have a range of [a, a+1) and for one I am using through implementation, [a, a+0.1). In either case I would have thought the semantic versioning tool should suggest a+0.1 as the next version for adding a new method, so as to enable the user to make that choice.
>
> What am I missing?
>
> Regards,
>
> Valentin
>
> On 29 Sep 2011, at 08:28, David Bosschaert wrote:
>
>> Hi Emily,
>>
>> Yes, sounds great. Especially if this plugin can ultimately be
>> integrated with maven and work alongside the maven-bundle-plugin that
>> would be great.
>>
>> Regarding the semantic versioning, this relates to the role that a
>> certain interface plays.
>> If an interface is extended (e.g. with a new method) then there are
>> two situations:
>> * if it's an interface that is supposed to be *implemented* by end
>> users then this is a major version increase. I think this is what you
>> have right now.
>> * however, if it's an interface that is supposed to be *used* by end
>> users but implemented by the infrastructure (e.g. part of the
>> 'project' you are comparing, which might span multiple bundles) then
>> only a minor version increase is needed. In this case the interface is
>> still binary compatible with users of it. It's just not compatible
>> with implementors of it. Note that this only applies to a limited set
>> of changes to an interface. E.g. removing a method is binary
>> incompatible for everyone.
>>
>> I'm not sure whether its possible to automatically guess what the role
>> of an interface is, so the tool needs to be configurable wrt to this.
>> I would even suggest that the tool fails unless this information is
>> available for all its public interfaces since guessing it wrong can
>> have pretty bad consequences.
>>
>> Cheers,
>>
>> David
>>
>> On 28 September 2011 19:36, Alasdair Nottingham <no...@apache.org> wrote:
>>> +1
>>>
>>> I think this would be a really good tool to have here. I'm happy to assist
>>> with getting it integrated if you need anything.
>>>
>>> Thanks
>>> Alasdair
>>>
>>> On 28 September 2011 17:17, Emily Jiang <em...@googlemail.com> wrote:
>>>
>>>> I use ASM and also have to load classes to access super classes:(.
>>>>
>>>> On Wed, Sep 28, 2011 at 5:10 PM, Timothy Ward <timothyjward@apache.org
>>>>> wrote:
>>>>
>>>>>
>>>>> Emily,
>>>>>
>>>>> Are you using ASM, or some other bytecode tool, to work out what has
>>>>> changed, or do you have to load classes and use reflection to find out?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Tim
>>>>>
>>>>>> Date: Wed, 28 Sep 2011 16:58:33 +0100
>>>>>> Subject: Re: Semantic Versioning tool
>>>>>> From: emijiang6@googlemail.com
>>>>>> To: dev@aries.apache.org
>>>>>>
>>>>>> Hi David,
>>>>>>
>>>>>> It works by comparing the current binary with the baseline binary:
>>>>>> 1. For each export package, it scans each non private class to see
>>>>> whether
>>>>>> there are binary incompatibility changes (according to Java
>>>>> specificiation
>>>>>> chapter 13 Binary Compability). If yes, a major version change is
>>>> needed
>>>>> for
>>>>>> this pkg.
>>>>>> 2. If there are not binary incompability changes, it will see whether
>>>>> there
>>>>>> are abstract class, methods or new xsd file added. If yes, the
>>>> package's
>>>>>> minor version needs to be increased.
>>>>>> 3. It then determine the bundle version based on package versions
>>>> changed
>>>>>> according to semantic versioning white paper.
>>>>>>
>>>>>> The tool ignore micro version changes.
>>>>>>
>>>>>> I can contribute the tool as a project and then we can create a mvn
>>>>> plugin
>>>>>> from it or something even smarter.
>>>>>>
>>>>>> Regards,
>>>>>> Emily
>>>>>>
>>>>>> On Wed, Sep 28, 2011 at 4:16 PM, David Bosschaert <
>>>>>> david.bosschaert@gmail.com> wrote:
>>>>>>
>>>>>>> Very interesting, Emily. Would you be able to provide some
>>>> information
>>>>>>> regarding how it works?
>>>>>>>
>>>>>>> In any case I would welcome such an addition to Aries.
>>>>>>>
>>>>>>> Best regards,
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>> On 28 September 2011 16:02, Emily Jiang <em...@googlemail.com>
>>>>> wrote:
>>>>>>>> I have developed a semantic checking tool to check whether a
>>>> bundle's
>>>>>>>> version or the export package versions are correclty versioned
>>>>> according
>>>>>>> to
>>>>>>>> OSGi semantic versioning whitepaper. I would like to contribute to
>>>>> Apache
>>>>>>>> Aries as subproject under a code name of 'llama' ( or a better
>>>> name.
>>>>> I am
>>>>>>>> open to suggestions).
>>>>>>>>
>>>>>>>> Any thoughts or suggestions?
>>>>>>>> --
>>>>>>>> Thanks
>>>>>>>> Emily
>>>>>>>> =================
>>>>>>>> Emily Jiang
>>>>>>>> ejiang@apache.org
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Thanks
>>>>>> Emily
>>>>>> =================
>>>>>> Emily Jiang
>>>>>> ejiang@apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Thanks
>>>> Emily
>>>> =================
>>>> Emily Jiang
>>>> ejiang@apache.org
>>>>
>>>
>>>
>>>
>>> --
>>> Alasdair Nottingham
>>> not@apache.org
>>>
>
>

Re: Semantic Versioning tool

[Valentin Mahrwald <vm...@googlemail.com>]

Hm, I thought the distinction between usage of the interface was a distinction made on the import side. So as for an interface I am using but not implementing I have a range of [a, a+1) and for one I am using through implementation, [a, a+0.1). In either case I would have thought the semantic versioning tool should suggest a+0.1 as the next version for adding a new method, so as to enable the user to make that choice.

What am I missing?

Regards,

Valentin

On 29 Sep 2011, at 08:28, David Bosschaert wrote:

> Hi Emily,
> 
> Yes, sounds great. Especially if this plugin can ultimately be
> integrated with maven and work alongside the maven-bundle-plugin that
> would be great.
> 
> Regarding the semantic versioning, this relates to the role that a
> certain interface plays.
> If an interface is extended (e.g. with a new method) then there are
> two situations:
> * if it's an interface that is supposed to be *implemented* by end
> users then this is a major version increase. I think this is what you
> have right now.
> * however, if it's an interface that is supposed to be *used* by end
> users but implemented by the infrastructure (e.g. part of the
> 'project' you are comparing, which might span multiple bundles) then
> only a minor version increase is needed. In this case the interface is
> still binary compatible with users of it. It's just not compatible
> with implementors of it. Note that this only applies to a limited set
> of changes to an interface. E.g. removing a method is binary
> incompatible for everyone.
> 
> I'm not sure whether its possible to automatically guess what the role
> of an interface is, so the tool needs to be configurable wrt to this.
> I would even suggest that the tool fails unless this information is
> available for all its public interfaces since guessing it wrong can
> have pretty bad consequences.
> 
> Cheers,
> 
> David
> 
> On 28 September 2011 19:36, Alasdair Nottingham <no...@apache.org> wrote:
>> +1
>> 
>> I think this would be a really good tool to have here. I'm happy to assist
>> with getting it integrated if you need anything.
>> 
>> Thanks
>> Alasdair
>> 
>> On 28 September 2011 17:17, Emily Jiang <em...@googlemail.com> wrote:
>> 
>>> I use ASM and also have to load classes to access super classes:(.
>>> 
>>> On Wed, Sep 28, 2011 at 5:10 PM, Timothy Ward <timothyjward@apache.org
>>>> wrote:
>>> 
>>>> 
>>>> Emily,
>>>> 
>>>> Are you using ASM, or some other bytecode tool, to work out what has
>>>> changed, or do you have to load classes and use reflection to find out?
>>>> 
>>>> Regards,
>>>> 
>>>> Tim
>>>> 
>>>>> Date: Wed, 28 Sep 2011 16:58:33 +0100
>>>>> Subject: Re: Semantic Versioning tool
>>>>> From: emijiang6@googlemail.com
>>>>> To: dev@aries.apache.org
>>>>> 
>>>>> Hi David,
>>>>> 
>>>>> It works by comparing the current binary with the baseline binary:
>>>>> 1. For each export package, it scans each non private class to see
>>>> whether
>>>>> there are binary incompatibility changes (according to Java
>>>> specificiation
>>>>> chapter 13 Binary Compability). If yes, a major version change is
>>> needed
>>>> for
>>>>> this pkg.
>>>>> 2. If there are not binary incompability changes, it will see whether
>>>> there
>>>>> are abstract class, methods or new xsd file added. If yes, the
>>> package's
>>>>> minor version needs to be increased.
>>>>> 3. It then determine the bundle version based on package versions
>>> changed
>>>>> according to semantic versioning white paper.
>>>>> 
>>>>> The tool ignore micro version changes.
>>>>> 
>>>>> I can contribute the tool as a project and then we can create a mvn
>>>> plugin
>>>>> from it or something even smarter.
>>>>> 
>>>>> Regards,
>>>>> Emily
>>>>> 
>>>>> On Wed, Sep 28, 2011 at 4:16 PM, David Bosschaert <
>>>>> david.bosschaert@gmail.com> wrote:
>>>>> 
>>>>>> Very interesting, Emily. Would you be able to provide some
>>> information
>>>>>> regarding how it works?
>>>>>> 
>>>>>> In any case I would welcome such an addition to Aries.
>>>>>> 
>>>>>> Best regards,
>>>>>> 
>>>>>> David
>>>>>> 
>>>>>> On 28 September 2011 16:02, Emily Jiang <em...@googlemail.com>
>>>> wrote:
>>>>>>> I have developed a semantic checking tool to check whether a
>>> bundle's
>>>>>>> version or the export package versions are correclty versioned
>>>> according
>>>>>> to
>>>>>>> OSGi semantic versioning whitepaper. I would like to contribute to
>>>> Apache
>>>>>>> Aries as subproject under a code name of 'llama' ( or a better
>>> name.
>>>> I am
>>>>>>> open to suggestions).
>>>>>>> 
>>>>>>> Any thoughts or suggestions?
>>>>>>> --
>>>>>>> Thanks
>>>>>>> Emily
>>>>>>> =================
>>>>>>> Emily Jiang
>>>>>>> ejiang@apache.org
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Thanks
>>>>> Emily
>>>>> =================
>>>>> Emily Jiang
>>>>> ejiang@apache.org
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Thanks
>>> Emily
>>> =================
>>> Emily Jiang
>>> ejiang@apache.org
>>> 
>> 
>> 
>> 
>> --
>> Alasdair Nottingham
>> not@apache.org
>> 

Re: Semantic Versioning tool

[David Bosschaert <da...@gmail.com>]

Hi Emily,

Yes, sounds great. Especially if this plugin can ultimately be
integrated with maven and work alongside the maven-bundle-plugin that
would be great.

Regarding the semantic versioning, this relates to the role that a
certain interface plays.
If an interface is extended (e.g. with a new method) then there are
two situations:
* if it's an interface that is supposed to be *implemented* by end
users then this is a major version increase. I think this is what you
have right now.
* however, if it's an interface that is supposed to be *used* by end
users but implemented by the infrastructure (e.g. part of the
'project' you are comparing, which might span multiple bundles) then
only a minor version increase is needed. In this case the interface is
still binary compatible with users of it. It's just not compatible
with implementors of it. Note that this only applies to a limited set
of changes to an interface. E.g. removing a method is binary
incompatible for everyone.

I'm not sure whether its possible to automatically guess what the role
of an interface is, so the tool needs to be configurable wrt to this.
I would even suggest that the tool fails unless this information is
available for all its public interfaces since guessing it wrong can
have pretty bad consequences.

Cheers,

David

On 28 September 2011 19:36, Alasdair Nottingham <no...@apache.org> wrote:
> +1
>
> I think this would be a really good tool to have here. I'm happy to assist
> with getting it integrated if you need anything.
>
> Thanks
> Alasdair
>
> On 28 September 2011 17:17, Emily Jiang <em...@googlemail.com> wrote:
>
>> I use ASM and also have to load classes to access super classes:(.
>>
>> On Wed, Sep 28, 2011 at 5:10 PM, Timothy Ward <timothyjward@apache.org
>> >wrote:
>>
>> >
>> > Emily,
>> >
>> > Are you using ASM, or some other bytecode tool, to work out what has
>> > changed, or do you have to load classes and use reflection to find out?
>> >
>> > Regards,
>> >
>> > Tim
>> >
>> > > Date: Wed, 28 Sep 2011 16:58:33 +0100
>> > > Subject: Re: Semantic Versioning tool
>> > > From: emijiang6@googlemail.com
>> > > To: dev@aries.apache.org
>> > >
>> > > Hi David,
>> > >
>> > > It works by comparing the current binary with the baseline binary:
>> > > 1. For each export package, it scans each non private class to see
>> > whether
>> > > there are binary incompatibility changes (according to Java
>> > specificiation
>> > > chapter 13 Binary Compability). If yes, a major version change is
>> needed
>> > for
>> > > this pkg.
>> > > 2. If there are not binary incompability changes, it will see whether
>> > there
>> > > are abstract class, methods or new xsd file added. If yes, the
>> package's
>> > > minor version needs to be increased.
>> > > 3. It then determine the bundle version based on package versions
>> changed
>> > > according to semantic versioning white paper.
>> > >
>> > > The tool ignore micro version changes.
>> > >
>> > > I can contribute the tool as a project and then we can create a mvn
>> > plugin
>> > > from it or something even smarter.
>> > >
>> > > Regards,
>> > > Emily
>> > >
>> > > On Wed, Sep 28, 2011 at 4:16 PM, David Bosschaert <
>> > > david.bosschaert@gmail.com> wrote:
>> > >
>> > > > Very interesting, Emily. Would you be able to provide some
>> information
>> > > > regarding how it works?
>> > > >
>> > > > In any case I would welcome such an addition to Aries.
>> > > >
>> > > > Best regards,
>> > > >
>> > > > David
>> > > >
>> > > > On 28 September 2011 16:02, Emily Jiang <em...@googlemail.com>
>> > wrote:
>> > > > > I have developed a semantic checking tool to check whether a
>> bundle's
>> > > > > version or the export package versions are correclty versioned
>> > according
>> > > > to
>> > > > > OSGi semantic versioning whitepaper. I would like to contribute to
>> > Apache
>> > > > > Aries as subproject under a code name of 'llama' ( or a better
>> name.
>> > I am
>> > > > > open to suggestions).
>> > > > >
>> > > > > Any thoughts or suggestions?
>> > > > > --
>> > > > > Thanks
>> > > > > Emily
>> > > > > =================
>> > > > > Emily Jiang
>> > > > > ejiang@apache.org
>> > > > >
>> > > >
>> > >
>> > >
>> > >
>> > > --
>> > > Thanks
>> > > Emily
>> > > =================
>> > > Emily Jiang
>> > > ejiang@apache.org
>> >
>> >
>>
>>
>>
>> --
>> Thanks
>> Emily
>> =================
>> Emily Jiang
>> ejiang@apache.org
>>
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
>

Re: Semantic Versioning tool

[Alasdair Nottingham <no...@apache.org>]

+1

I think this would be a really good tool to have here. I'm happy to assist
with getting it integrated if you need anything.

Thanks
Alasdair

On 28 September 2011 17:17, Emily Jiang <em...@googlemail.com> wrote:

> I use ASM and also have to load classes to access super classes:(.
>
> On Wed, Sep 28, 2011 at 5:10 PM, Timothy Ward <timothyjward@apache.org
> >wrote:
>
> >
> > Emily,
> >
> > Are you using ASM, or some other bytecode tool, to work out what has
> > changed, or do you have to load classes and use reflection to find out?
> >
> > Regards,
> >
> > Tim
> >
> > > Date: Wed, 28 Sep 2011 16:58:33 +0100
> > > Subject: Re: Semantic Versioning tool
> > > From: emijiang6@googlemail.com
> > > To: dev@aries.apache.org
> > >
> > > Hi David,
> > >
> > > It works by comparing the current binary with the baseline binary:
> > > 1. For each export package, it scans each non private class to see
> > whether
> > > there are binary incompatibility changes (according to Java
> > specificiation
> > > chapter 13 Binary Compability). If yes, a major version change is
> needed
> > for
> > > this pkg.
> > > 2. If there are not binary incompability changes, it will see whether
> > there
> > > are abstract class, methods or new xsd file added. If yes, the
> package's
> > > minor version needs to be increased.
> > > 3. It then determine the bundle version based on package versions
> changed
> > > according to semantic versioning white paper.
> > >
> > > The tool ignore micro version changes.
> > >
> > > I can contribute the tool as a project and then we can create a mvn
> > plugin
> > > from it or something even smarter.
> > >
> > > Regards,
> > > Emily
> > >
> > > On Wed, Sep 28, 2011 at 4:16 PM, David Bosschaert <
> > > david.bosschaert@gmail.com> wrote:
> > >
> > > > Very interesting, Emily. Would you be able to provide some
> information
> > > > regarding how it works?
> > > >
> > > > In any case I would welcome such an addition to Aries.
> > > >
> > > > Best regards,
> > > >
> > > > David
> > > >
> > > > On 28 September 2011 16:02, Emily Jiang <em...@googlemail.com>
> > wrote:
> > > > > I have developed a semantic checking tool to check whether a
> bundle's
> > > > > version or the export package versions are correclty versioned
> > according
> > > > to
> > > > > OSGi semantic versioning whitepaper. I would like to contribute to
> > Apache
> > > > > Aries as subproject under a code name of 'llama' ( or a better
> name.
> > I am
> > > > > open to suggestions).
> > > > >
> > > > > Any thoughts or suggestions?
> > > > > --
> > > > > Thanks
> > > > > Emily
> > > > > =================
> > > > > Emily Jiang
> > > > > ejiang@apache.org
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Thanks
> > > Emily
> > > =================
> > > Emily Jiang
> > > ejiang@apache.org
> >
> >
>
>
>
> --
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang@apache.org
>



-- 
Alasdair Nottingham
not@apache.org

Re: Semantic Versioning tool

[Emily Jiang <em...@googlemail.com>]

I use ASM and also have to load classes to access super classes:(.

On Wed, Sep 28, 2011 at 5:10 PM, Timothy Ward <ti...@apache.org>wrote:

>
> Emily,
>
> Are you using ASM, or some other bytecode tool, to work out what has
> changed, or do you have to load classes and use reflection to find out?
>
> Regards,
>
> Tim
>
> > Date: Wed, 28 Sep 2011 16:58:33 +0100
> > Subject: Re: Semantic Versioning tool
> > From: emijiang6@googlemail.com
> > To: dev@aries.apache.org
> >
> > Hi David,
> >
> > It works by comparing the current binary with the baseline binary:
> > 1. For each export package, it scans each non private class to see
> whether
> > there are binary incompatibility changes (according to Java
> specificiation
> > chapter 13 Binary Compability). If yes, a major version change is needed
> for
> > this pkg.
> > 2. If there are not binary incompability changes, it will see whether
> there
> > are abstract class, methods or new xsd file added. If yes, the package's
> > minor version needs to be increased.
> > 3. It then determine the bundle version based on package versions changed
> > according to semantic versioning white paper.
> >
> > The tool ignore micro version changes.
> >
> > I can contribute the tool as a project and then we can create a mvn
> plugin
> > from it or something even smarter.
> >
> > Regards,
> > Emily
> >
> > On Wed, Sep 28, 2011 at 4:16 PM, David Bosschaert <
> > david.bosschaert@gmail.com> wrote:
> >
> > > Very interesting, Emily. Would you be able to provide some information
> > > regarding how it works?
> > >
> > > In any case I would welcome such an addition to Aries.
> > >
> > > Best regards,
> > >
> > > David
> > >
> > > On 28 September 2011 16:02, Emily Jiang <em...@googlemail.com>
> wrote:
> > > > I have developed a semantic checking tool to check whether a bundle's
> > > > version or the export package versions are correclty versioned
> according
> > > to
> > > > OSGi semantic versioning whitepaper. I would like to contribute to
> Apache
> > > > Aries as subproject under a code name of 'llama' ( or a better name.
> I am
> > > > open to suggestions).
> > > >
> > > > Any thoughts or suggestions?
> > > > --
> > > > Thanks
> > > > Emily
> > > > =================
> > > > Emily Jiang
> > > > ejiang@apache.org
> > > >
> > >
> >
> >
> >
> > --
> > Thanks
> > Emily
> > =================
> > Emily Jiang
> > ejiang@apache.org
>
>



-- 
Thanks
Emily
=================
Emily Jiang
ejiang@apache.org

RE: Semantic Versioning tool

[Timothy Ward <ti...@apache.org>]

Emily,

Are you using ASM, or some other bytecode tool, to work out what has changed, or do you have to load classes and use reflection to find out?

Regards,

Tim

> Date: Wed, 28 Sep 2011 16:58:33 +0100
> Subject: Re: Semantic Versioning tool
> From: emijiang6@googlemail.com
> To: dev@aries.apache.org
> 
> Hi David,
> 
> It works by comparing the current binary with the baseline binary:
> 1. For each export package, it scans each non private class to see whether
> there are binary incompatibility changes (according to Java specificiation
> chapter 13 Binary Compability). If yes, a major version change is needed for
> this pkg.
> 2. If there are not binary incompability changes, it will see whether there
> are abstract class, methods or new xsd file added. If yes, the package's
> minor version needs to be increased.
> 3. It then determine the bundle version based on package versions changed
> according to semantic versioning white paper.
> 
> The tool ignore micro version changes.
> 
> I can contribute the tool as a project and then we can create a mvn plugin
> from it or something even smarter.
> 
> Regards,
> Emily
> 
> On Wed, Sep 28, 2011 at 4:16 PM, David Bosschaert <
> david.bosschaert@gmail.com> wrote:
> 
> > Very interesting, Emily. Would you be able to provide some information
> > regarding how it works?
> >
> > In any case I would welcome such an addition to Aries.
> >
> > Best regards,
> >
> > David
> >
> > On 28 September 2011 16:02, Emily Jiang <em...@googlemail.com> wrote:
> > > I have developed a semantic checking tool to check whether a bundle's
> > > version or the export package versions are correclty versioned according
> > to
> > > OSGi semantic versioning whitepaper. I would like to contribute to Apache
> > > Aries as subproject under a code name of 'llama' ( or a better name. I am
> > > open to suggestions).
> > >
> > > Any thoughts or suggestions?
> > > --
> > > Thanks
> > > Emily
> > > =================
> > > Emily Jiang
> > > ejiang@apache.org
> > >
> >
> 
> 
> 
> -- 
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang@apache.org
 		 	   		  

Re: Semantic Versioning tool

[Emily Jiang <em...@googlemail.com>]

Hi David,

It works by comparing the current binary with the baseline binary:
1. For each export package, it scans each non private class to see whether
there are binary incompatibility changes (according to Java specificiation
chapter 13 Binary Compability). If yes, a major version change is needed for
this pkg.
2. If there are not binary incompability changes, it will see whether there
are abstract class, methods or new xsd file added. If yes, the package's
minor version needs to be increased.
3. It then determine the bundle version based on package versions changed
according to semantic versioning white paper.

The tool ignore micro version changes.

I can contribute the tool as a project and then we can create a mvn plugin
from it or something even smarter.

Regards,
Emily

On Wed, Sep 28, 2011 at 4:16 PM, David Bosschaert <
david.bosschaert@gmail.com> wrote:

> Very interesting, Emily. Would you be able to provide some information
> regarding how it works?
>
> In any case I would welcome such an addition to Aries.
>
> Best regards,
>
> David
>
> On 28 September 2011 16:02, Emily Jiang <em...@googlemail.com> wrote:
> > I have developed a semantic checking tool to check whether a bundle's
> > version or the export package versions are correclty versioned according
> to
> > OSGi semantic versioning whitepaper. I would like to contribute to Apache
> > Aries as subproject under a code name of 'llama' ( or a better name. I am
> > open to suggestions).
> >
> > Any thoughts or suggestions?
> > --
> > Thanks
> > Emily
> > =================
> > Emily Jiang
> > ejiang@apache.org
> >
>



-- 
Thanks
Emily
=================
Emily Jiang
ejiang@apache.org

Re: Semantic Versioning tool

[David Bosschaert <da...@gmail.com>]

Very interesting, Emily. Would you be able to provide some information
regarding how it works?

In any case I would welcome such an addition to Aries.

Best regards,

David

On 28 September 2011 16:02, Emily Jiang <em...@googlemail.com> wrote:
> I have developed a semantic checking tool to check whether a bundle's
> version or the export package versions are correclty versioned according to
> OSGi semantic versioning whitepaper. I would like to contribute to Apache
> Aries as subproject under a code name of 'llama' ( or a better name. I am
> open to suggestions).
>
> Any thoughts or suggestions?
> --
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang@apache.org
>