Re: [cross-project-issues-dev] Unannounced Changes Have Unforeseen Consequences

[Michael Scharf]

Indeed, breaking API without major version changes is an absolute no go. Even if only a few percent of existing plugins are affected, this undermines the idea of APIs and semantic versioning. see also https://wiki.eclipse.org/Evolving_Java-based_APIs   API Prime Directive: When evolving the Component API from release to release, do not break existing Clients.     API Contract Compatibility: API changes must not invalidate formerly legal Client code.     API Usage Assumption: Every aspect of the API matters to some Client.     API Binary Compatibility: Pre-existing Client binaries must link and run with new releases of the Component without recompiling. Michael On 2015-09-14 15:03, Ed Willink wrote: Hi This discussion seems to completely ignore: The major segment number must be increased when a plug-in makes breaking changes to its API. see https://wiki.eclipse.org/Version_Numbering#When_to_change_the_major_segment Deprecation permits breakage but not violation of versioning. It is certainly very inconvenient to maintain API forever, but arbitrary deletion without a consistent version number change is just dishonest; we have distributed code that claims to work and it won't. Perhaps the solution is for the platform to have a major version increase every two/three years allowing API clean up. Other projects will be more or less forced to synchronize which will be a nuisance, but also a benefit, since they too can clean up their APIs. Let Neon be versioned as 5.0.0 and we can all clean up.     Regards         Ed Willink

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