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].
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=475833#c15
Cheers,
Ian
On Sat, Sep 12, 2015 at 10:05 AM, Doug Schaefer <dschae...@qnx.com
<mailto:dschae...@qnx.com>> wrote:
This affected CDT too. Luckily we were some what prepared and had
one or
our crack committers fix it but it did force us to make a change to
continue on with Neon.
So, I¹m not sure how this is not an API breaking change, deprecated or
not. I believe the Platform is going to have to ask the Planning
Council
for an exception for this and get their approval.
Doug.
On 2015-09-12, 4:32 AM,
"cross-project-issues-dev-boun...@eclipse.org
<mailto:cross-project-issues-dev-boun...@eclipse.org> on
behalf of Ed Willink"
<cross-project-issues-dev-boun...@eclipse.org
<mailto:cross-project-issues-dev-boun...@eclipse.org> on
behalf of e...@willink.me.uk <mailto:e...@willink.me.uk>> wrote:
>Hi
>
>TableTreeViewer removal was announced in
>
>http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.platform.doc.i
>sv%2Fporting%2Fremovals.html
>
>But IPlatformRunnable is only announced as after June 2017 in
>
>http://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.platform.doc.i
>sv%2Fporting%2Fremovals.html
>
>so the discussed removal in
>
>https://bugs.eclipse.org/bugs/show_bug.cgi?id=475944
>
>seems premature.
>
> Regards
>
> Ed Willink
>
>On 12/09/2015 09:05, Ed Merks wrote:
>> Hi,
>>
>> It was brought to my attention that
>> org.eclipse.jface.viewers.TableTreeViewer has been deleted. Yes, I
>> know it's deprecated, but nevertheless it was once API before being
>> deprecated so deleting it is a breaking change. I don't recall
there
>> being an announcement to begin deleting arbitrary deprecated API.
>>
>> In any case, I can't necessarily commit to making the necessary
>> changes. As such I can't commit to contributing EMF Core to Neon.
>>
>> I would suggest reconsidering the strategy of breaking APIs and
most
>> certainly suggest any such actions ought to be announced and
discussed
>> before such actions are taken.
>>
>> Regards,
>> Ed
>> _______________________________________________
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
<mailto: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
>>
>>
>> -----
>> No virus found in this message.
>> Checked by AVG - www.avg.com <http://www.avg.com>
>> Version: 2015.0.6125 / Virus Database: 4419/10626 - Release Date:
>> 09/12/15
>>
>>
>
>_______________________________________________
>cross-project-issues-dev mailing list
>cross-project-issues-dev@eclipse.org
<mailto: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
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
<mailto: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
--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource
_______________________________________________
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
_______________________________________________
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