| Re: [cross-project-issues-dev] Unannounced Changes Have Unforeseen Consequences |
|
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:
|