Sorry to rehash old questions - but I wasn't active when this was first discussed. CDT has recently taken on this policy (but not used it yet):
Why is API removed from Eclipse without bumping the major version number? i.e the "In general, removing a deprecated API does NOT cause the increase of the major version segment." in https://wiki.eclipse.org/Eclipse/API_Central/API_Removal_Process Thanks Jonah ~~~ Jonah Graham Kichwa Coders www.kichwacoders.com On Fri, 18 Sep 2020 at 09:43, Aleksandar Kurtakov <akurt...@redhat.com> wrote: > > > On Fri, Sep 18, 2020 at 12:30 PM Aleksandar Kurtakov <akurt...@redhat.com> > wrote: > >> >> >> On Fri, Sep 18, 2020 at 11:27 AM Wim Jongman <wim.jong...@gmail.com> >> wrote: >> >>> >>> 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. >>> >> >> API is deprecated for at least 2 years before being removed so if a >> project has deprecations free build with the 2 years old version it will >> work fine with the latest release. >> >> >>> >>> 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 :) >>> >> >> That ^^ is no longer true for Java too. >> https://www.oracle.com/java/technologies/javase/jdk-11-relnote.html#Removed >> and continues in newer versions. >> > > I just can't resist sending this link here > https://www.eclipse.org/lists/cdt-dev/msg34634.html . > Java and the overall software world are changing on an ever increasing > pace - no matter whether we accept it, like it or not. Thus LTS (the old > 10+ years) is gone - no matter how hard it is tried it will become harder > and harder and admitting that can save us quite a lot of frustration. One > can look at what is the current "extended" support e.g. Firefox does it > roughly for a year. And we live in that reality - JVMs break API on 6 > months, GTK will have more than a huge change very shortly (4.x), latest > MacOS requires changing the binaries produced due to new CPU architecture, > IE is being replaced by Chrome engine powered engine and so on and on. With > all that said - either projects start working on their deps to keep the > support for things for longer or it will be gone not because WE WANT to > remove it but because WE HAVE to in order to throw the next release out and > keep it working on the new versions of our dependencies. > P.S. Before anyone brings the paid vs rest developers conversation again I > want to make smth crystal clear - No one just pays anyone to work on > whatever he wants in whatever way he wants if you find such a place let me > know. With faster and faster ecosystem changes an official task (aka being > paid for) for some of us is "REDUCE MAINTENANCE COST" and getting the blame > for not going to the extend that someone would like to see it while moving > like a snake (compared to other projects with which you compete for > resources) definitely has a positive and thankful effect for spending "my > own time" (quotes on purpose) trying to keep things going in the least > disruptive way possible while still preserving people to work on the > "thing". > P.S. 2 I would love to be pointed to another RCP/IDE platform that takes > backward compatibility more seriously than Eclipse TLP!!! > > >> >> >>> >>> Cheers, >>> >>> Wim >>> >>> _______________________________________________ >>> platform-dev mailing list >>> platform-dev@eclipse.org >>> To unsubscribe from this list, visit >>> https://www.eclipse.org/mailman/listinfo/platform-dev >>> >> >> >> -- >> Alexander Kurtakov >> Red Hat Eclipse Team >> > > > -- > Alexander Kurtakov > Red Hat Eclipse Team > _______________________________________________ > platform-dev mailing list > platform-dev@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/platform-dev >
_______________________________________________ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
