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

[Michael Scharf <eclipse@xxxxxxxxx>]

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