> 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
_______________________________________________ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
