[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [platform-dev] Recent API Removal breaks clients
|
GuysA 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,DaniFrom:
Wim
Jongman <wim.jongman@xxxxxxxxx>To:
"Eclipse
platform general developers list." <platform-dev@xxxxxxxxxxx>Date:
18.09.2020
16:59Subject:
[EXTERNAL]
Re: [platform-dev] Recent API Removal breaks clientsSent
by: platform-dev-bounces@xxxxxxxxxxx
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,WimOn Fri, Sep 18, 2020 at 3:43 PM Aleksandar
Kurtakov <akurtako@xxxxxxxxxx>
wrote:On Fri, Sep 18, 2020 at 12:30 PM Aleksandar
Kurtakov <akurtako@xxxxxxxxxx>
wrote:On Fri, Sep 18, 2020 at 11:27 AM Wim
Jongman <wim.jongman@xxxxxxxxx>
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#Removedand 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@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
-- Alexander KurtakovRed Hat Eclipse Team
-- Alexander KurtakovRed Hat Eclipse Team_______________________________________________
platform-dev mailing list
platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev_______________________________________________
platform-dev mailing list
platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev