Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Unannounced Changes Have Unforeseen Consequences

Hi,

I totally second Eds and Eds remarks here. All API policies and all the bundle versioning schemes and careful changes in the past would be rendered pointless with this move. I doubt that keeping the deprecated interfaces is causing effort for the maintainers that is coming even remotely close to the pain that clients of existing, potentially broken plugins would suffer from.

I strongly recommend to weigh the benefits of removing a few lines of code from the repo against the potential harm that this will cause. If and only if the deprecated APIs get in the way of successful platform evolution, it would seem to be reasonable to discuss a major version increment along with the breakage. But even a major increment wouldn't imply that all the deprecated code should be blindly removed since deprecated doesn't mean something's not working anymore. I'm pretty sure that the backwards compatibility is a major success factor for Eclipse as a platform and we shouldn't give that away because of an intrinsic motivation to cleanup a few lines of code.

Best regards,
Sebastian

On Mon, 14 Sep 2015 at 15:03 Ed Willink <ed@xxxxxxxxxxxxx> 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



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

On Sat, Sep 12, 2015 at 10:05 AM, Doug Schaefer <dschaefer@xxxxxxx> 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-bounces@xxxxxxxxxxx on
behalf of Ed Willink" <cross-project-issues-dev-bounces@xxxxxxxxxxx on
behalf of ed@xxxxxxxxxxxxx> 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@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/10626 - Release Date:
>> 09/12/15
>>
>>
>
>_______________________________________________
>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



--
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@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


_______________________________________________
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

Back to the top