Can we take this discussion into a bugreport and remove it from crossproject and then everyone interested in seeing you hitting Konstantin can subscribe….
christian Von: <[email protected]<mailto:[email protected]>> on behalf of John Arthorne <[email protected]<mailto:[email protected]>> Antworten an: Cross issues <[email protected]<mailto:[email protected]>> Datum: Mittwoch, 28. Oktober 2015 um 16:54 An: Cross issues <[email protected]<mailto:[email protected]>> Betreff: Re: [cross-project-issues-dev] DTP major version bump for Neon >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 <[email protected]<mailto:[email protected]>> To: John Arthorne/Ottawa/IBM@IBMCA, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> 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: [email protected]<mailto:[email protected]> 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 <[email protected]<mailto:[email protected]>> Sent by: [email protected]<mailto:[email protected]> To: Ed Willink <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> 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: [email protected]<mailto:[email protected]> 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 [email protected]<mailto:[email protected]> To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ------------------------------------------------------------- compeople AG Untermainanlage 8 60329 Frankfurt/Main fon: +49 (0) 69 / 27 22 18 0 fax: +49 (0) 69 / 27 22 18 22 web: www.compeople.de Vorstand: Jürgen Wiesmaier Aufsichtsratsvorsitzender: Christian Glanz Sitz der Gesellschaft: Frankfurt/Main Handelsregister Frankfurt HRB 56759 USt-IdNr. DE207665352 -------------------------------------------------------------
_______________________________________________ cross-project-issues-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
