Re: [cross-project-issues-dev] DTP major version bump for Neon

["John Arthorne" <John_Arthorne@xxxxxxxxxx>]

>And here lies the crux of our disagreement. I take an absolute position on this issue. Potentially not breaking a >consumer with an existing DTP installation is not the same as not breaking them. Any other position throws into >question why we even bother having a versioning convention. By definition, any API change can be >characterized as potentially having no impact.

 

Yes, your approach does guarantee a breaking change for all clients, whereas updating the BREE only impacts consumers that are actually affected by the change. Congratulations on achieving consistency on that :)

 

John

 

 

----- Original message -----
From: Konstantin Komissarchik <konstantin.komissarchik@xxxxxxxxxx>
To: John Arthorne/Ottawa/IBM@IBMCA, "cross-project-issues-dev@xxxxxxxxxxx" <cross-project-issues-dev@xxxxxxxxxxx>
Cc:
Subject: RE: [cross-project-issues-dev] DTP major version bump for Neon
Date: Wed, Oct 28, 2015 11:24 AM
 

> potentially no impact on most consumers of your API

 

And here lies the crux of our disagreement. I take an absolute position on this issue. Potentially not breaking a consumer with an existing DTP installation is not the same as not breaking them. Any other position throws into question why we even bother having a versioning convention. By definition, any API change can be characterized as potentially having no impact.

 

- Konstantin

 

 

From: John Arthorne
Sent: Wednesday, October 28, 2015 8:07 AM
To: cross-project-issues-dev@xxxxxxxxxxx
Subject: Re: [cross-project-issues-dev] DTP major version bump for Neon

 

 

> I understand the temptation to fudge the truth when it comes to version numbers, but that doesn’t make it a sound engineering practice.

 

You appear to be the first person to claim that making version numbers reflect changes to runtime dependencies is sound engineering practice. Even Java itself did not update its major version with Java 8 (which is officially version 1.8 at the JVM level). Changes to your dependencies have no direct impact on your API, and potentially no impact on most consumers of your API. A consumer of your bundle may already have a dependency on Java 8 (or whatever the case may be), and therefore could not possibly be impacted by your change. By updating your BREE, you have ensured that your bundle will not even be loaded by OSGi in a runtime using Java 7 or earlier, which is already a strong enough hint to any consumer impacted by this change. Updating the bundle version number as well offers absolutely no benefit.

 

I will agree with Alex, that as the person doing the work you have the right to make these changes, however unjustified. The consumer community will have to react accordingly (by updating manifests, contributing to the project, removing the dependency, forking, etc).

 

John

 

----- Original message -----
From: Konstantin Komissarchik <konstantin.komissarchik@xxxxxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
To: Ed Willink <ed@xxxxxxxxxxxxx>, "cross-project-issues-dev@xxxxxxxxxxx" <cross-project-issues-dev@xxxxxxxxxxx>
Cc:
Subject: Re: [cross-project-issues-dev] DTP major version bump for Neon
Date: Wed, Oct 28, 2015 9:45 AM
 

I gave the justification several times. You are choosing to disregard it. Java API is not bundle’s sole API. I don’t consider a restriction in requirements a compatible change. DTP 2 is certainly not a drop-in replacement for DTP 1.12 and the version numbering truthfully communicates that fact.

 

I understand the temptation to fudge the truth when it comes to version numbers, but that doesn’t make it a sound engineering practice.

 

- Konstantin

 

 

From: Ed Willink
Sent: Wednesday, October 28, 2015 6:29 AM
To: cross-project-issues-dev@xxxxxxxxxxx
Subject: Re: [cross-project-issues-dev] DTP major version bump for Neon

 

 

 

On 28/10/2015 13:13, Konstantin Komissarchik wrote:

 

 

I have no specific plans re ODA’s Java API.

 

 

So absolutely no justification for a change then. There is no need for all plugins to bump together. It is cosmetically nice to see all plugins with the same version, but it just isn't tenable long term.

For instance many OCL plugins remain at 3.x although those that have been affected by UML major changes have moved to 4.x and 5.x.

Inflicting a major change on clients is not a bit of a pain, it is a major pain, particularly for those clients that are stable and consequently have minimal maintenance teams. In some cases useful but unmaintained tools, such as UML2 Tools, are killed by the major version change.

    Regards

        Ed Willink

 

 

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev