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@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
