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
On 14/09/2015 08:31, Ed Merks wrote:
Ian,
That's exactly the key issue that concerns me most. In general
I've felt uncomfortable with the version ranges for two reasons.
Firstly because I believe that once set, the lower bound is likely
never carefully reconsidered as to whether it remains valid. As
such, I'm willing to bet that a large portion, if not the the vast
majority of the bundles, have invalid lower bounds. Secondly
because the upper bound is a guess; exclusion of a major increment
is the common best guess. Now it's clear to me that even this is
generally a bogus guess because any API can become deprecated
(which is not a problem), but furthermore eventually can be
removed, without the corresponding major version increment. So
older EMF bundles claiming to working with any 3.x version of
Eclipse will not behave as expected and therefore definitely they
each have a bogus upper bound. Maybe others are comfortable with
all this, but personally I am not.
EMF maintains compatibility back to Eclipse 3.6, to make reuse of
the latest version as flexible as possible for the broadest
audience of clients as possible. We build against 3.6 and
generate version ranges based on what we build against (ensuring
they aren't bogus). Currently I'm working towards EMF 2.12, i.e.,
12 years of binary compatibility, and I'm personally not
comfortable removing public methods, even if they are deprecated,
while still claiming it's a 2.12 version.
In any case, I was not aware that this was a general policy for
the platform. Perhaps I'm not the only one. I think deletions
ought to be announced, and with sufficient advanced waning...
Regardless of how many projects are directly affected, a great
many projects are indirectly affected when EMF is affected, i.e.,
notification-based updates of viewers will no longer work because
of missing class exceptions. So a good portion of Neon will
simply not function. I wonder when that would be (will be) first
be noticed?
On 14/09/2015 6:45 AM, Ian Bull
wrote:
The reason it was not considered an API breaking
change was explained to me in [1].
Cheers,
Ian
_______________________________________________
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.6125 / Virus Database: 4419/10637 - Release
Date: 09/14/15
|