[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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
On 18.09.2020 10:26, Wim Jongman 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.
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