| Re: [platform-dev] Recent API Removal breaks clients |
Wim,
I empathize with these concerns. To prevent such problems, EMF's builds and test against a great many target platforms:
https://ci.eclipse.org/emf/job/all-target-platforms/
This job builds the latest source and runs all the tests against
helios and higher. This was of course a lot of work to implement
and is significant work to maintain; EMF takes Long Term Support
very seriously.
Every time yet another thing is deprecated I cringe. I maintain
warning free code so I notice! And then the threat of removal
always looms on the horizon. So when
IProgressMonitorWithBlocking was deprecated, I notice, and then I
notice too that it's in EMF's API, so the threat of removal means
that I must break APIs should that come to pass. But I don't
break EMF's APIs, and I don't want break EMF's APIs. Do I have a
choice? Does my opinion matter? Not so much.
In this case, when I point out that if I were to actually try to
remove my uses, that I would break behavior because the platform
as a whole has not altered the code to make implementing
IProgressMonitorWithBlocking redundant, I'm told that will happen
later in the next release cycle.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=552683#c25
I don't comprehend the
deprecate-now-but-don't-do-anything-about-it-until-later reasoning
and I'm super frustrated by the constant threat of breakage. As a
word of caution, if IProgressMonitorWithBlocking is removed, EMF's
build will become the progress monitor that blocks it. I will
make my opinion matter.
While I'm ranting and making myself unpopular, I look at p2's bug list and see that it's never reduced. Instead there are disruptive changes that I'd rather not see:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=566070
https://bugs.eclipse.org/bugs/show_bug.cgi?id=567030
Does my opinion matter? Not so much. Unfortunately Oomph has
many wickedly-evil dependencies p2 so, in some ways, lack of
change there is good...
I'm not being paid to maintain EMF/XSD, Oomph (and the
installer), and JustJ, but others are being paid and while it's
most definitely none of my business, I'd so much rather see the
time spent fixing bugs than on constant cleanup activities,
especially the disruptive ones. If I were to spend a lot of time
on cleanup activities, I would try to eliminate the 20,000
warnings I see in my SDK workspace.
I apologize in advanced to those whose shorts get in a knot over
these comments. No offense is intended. This is an issue of
community perception and the broader community doesn't perceive
the vibrant, active developer community we have on the platform;
one that I'm very grateful to have and to be a part of. The key
take-away is that the community generally only perceives the end
result.
For example, the community doesn't perceive the goodness from
this:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=527378
But rather perceives the bug that it causes:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=566642
Every time we delete something (even if it's internal non-API),
we will definitely break something and someone, sometimes even our
own stuff. Typically the end user is the first one who notices
that, after the release, and that user perceives this problem as
"Eclipse". Even at Eclipse, not every project downstream from the
platform has a rich, active, vibrant community to maintain their
code base and release 4 times a year. Many, if not most, rely on
the stability and quality of the platform, and when things are
deleted 4 times per year, at arbitrary points in the cycle, it's
hard to keep up with the goodness.
Even the move to Java 11 has been super disruptive to our
community; at least I assume so because it was super disruptive
for me personally. Of course this move is totally justified and
is arguably goodness, but how many things will be broken by the
move to Java 11, like this:
https://www.eclipse.org/forums/index.php/mv/msg/1105256/1832430/#msg_1832430
Probably not so many because this is a corner case.
I definitely worked my assets off to ensure that the installer
would run out-of-the-box for 2020-09 and would even install a JRE
if the user doesn't have a Java 11 installation available because
I'm well aware that the failure to do so would reflect poorly on
"Eclipse". And I take LTS very seriously.
Again, I apologize in advance for any offense taken. None is
intended. We all want "Eclipse" to be great and do what we do to
help ensure that's the case. I just feel that the various points
of view involved could be more balanced if more of them would be
considered relevant.
Regards,
Ed
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@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev