Re: [platform-dev] Recent API Removal breaks clients

[Wim Jongman <wim.jongman@xxxxxxxxx>]

Should we not support older versions of Eclipse?

There is 2 years notice period so I would say do not support versions older than 2 years.

We provide LTS so it is not possible for everyone. It would also not catch the API break in the i-build.

1. The person that proposes the API change makes an impact analysis by searching all the Eclipse repositories, removal is abandoned if used > x%

2. Removal of API is sent to the mailing list of the project that uses the API so that we can fix things in time, especially when the project is in maintenance mode.

1. and 2. are not realistic if we go that path why don't we add Spring Tools or JBoss Tools which are one of the widely used plugins out there. Why not add Pydev too? Requiring to subscribe to project list to notify is a bit too much for me. There is a reason we have cross-project list. Effectively this proposal is to never ever change anything and let Eclipse Platform collapse under its own weight where we keep shipping multiple ways to do things - each with its own oddities.

Yes, we should add them as well. It is also about the thousands of consumers that we don't know.

And I really don't think that leaving three lines in Platform will cause Eclipse to collapse under its own weight. Java has never removed a deprecated method or an API class. AFAICT, they are fine :)

Cheers,

Wim