Guys A lot of people watch this list and are not interested in this discussion. Can you please move it to a bug report. Also, I suggest to back your statements with data/facts, e.g. links to specs, Eclipse API docs etc.
Thanks, Dani From: Wim Jongman <wim.jong...@gmail.com> To: "Eclipse platform general developers list." <platform-dev@eclipse.org> Date: 18.09.2020 16:59 Subject: [EXTERNAL] Re: [platform-dev] Recent API Removal breaks clients Sent by: platform-dev-boun...@eclipse.org Brothers, I think we all can see each other's position. Our API must be kept clean but... This Message Is From an External Sender This message came from outside your organization. Brothers, I think we all can see each other's position. Our API must be kept clean but we also don't want to break the projects that rely on our platform. The fact that this discussion is coming back is an indicator that some things can be improved. So if we can all agree on that, let's see if we can implement _all_ of the following. 1. Purge deprecated API as we do now. 2. Define the criteria for a drawback request. 3. Implement a better warning system. If all say aye, I will open bugs for points 2 and 3. Cheers, Wim On Fri, Sep 18, 2020 at 3:43 PM 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
_______________________________________________ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
