[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] DTP major version bump for Neon

Hi

Perhaps you can just follow the community experience.

You don't have to change your BREE at all, but you will still impose a Java 8 BREE on your Neon customers, since the platform already has a Job component that requires Java 8. I am not aware of anyone suggesting that this BREE change requires the platform move to e5.

I also write from direct experience. When I took over OCL, I found that UML was taking a major version change requiring an OCL move from version 2.x to 3.x. I mistakenly thought that the previous failure of other plugins to move from 1.x to 2.x was a historical mistake, so I corrected it. Everything became nice and simple; 3.x all round. Except that client builds broke. With the benefit of experience I now know that the 1.x plugins could still be 1.x many years later and I need never have inflicted the pain on my clients. (Belated apologies to them.)

ÂÂÂ Regards

ÂÂÂ ÂÂÂ Ed Willink

On 28/10/2015 15:24, Konstantin Komissarchik wrote:

> 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

Â

Â

Â

Â



_______________________________________________
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


No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6173 / Virus Database: 4455/10902 - Release Date: 10/28/15