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
|