[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [platform-dev] Recent API Removal breaks clients
|
Maybe it would be useful if the version number had an additional
segement:
major.new-segment.minor.service
new-segment could be increased for removals, and an increase would
signal something like this:
"This change is backwards compatible EXCEPT for the removal of
deprecated things which have been clearly announced a long time in
advance."
Of course this is just hypothetical, it's not possible to add a segment
like this.
/Jens
2020-09-20 10:28 skrev Ed Merks:
Peter,
Comments below.
On 19.09.2020 11:51, Peter Kriens wrote:
So what is the purpose of version numbers if you start lying about
their semantics?
The concern is that the cure (major version increments) is as
disruptive and painful as the disease (deleting/breaking API).
Assuming an API has been deprecated for a long time and that the
clients have all had sufficient time to stop using it and have done
so, the only remaining diseased part is in the bundle providing that
"API.". Here the disease can be excised easily by a single
committer. But, if we now also increment the major version number,
the resulting symptoms are exactly the same as the disease: all
clients are broken and all clients will yet again have to revisit all
their code to bump the upper bound of all their bundles. This
approach guarantees that the entire downstream client base stops
working after each and every deletion.
Surely in this light, this is not a feasible strategy for the
platform's gigantic downstream ecoystem...
I agree that it semantic version does take an effort to get started
with but from extensive experience I can promise you that this is a
one time effort and pays off handsomely in much more control over the
process.
If it were just within one project or the downstream consumer base is
small, that of course makes good sense. But with the platform as
just the tip of the iceberg, I don't believe we should realistically
expect the entire ecosystem to be quite so enamored with this
approach.
However, having versions but then not using their semantics is
probably the worst of both worlds.
It's all about balance. However factually and technically correct you
are (and you definitely are), the practical reality of a huge,
poorly-maintained, downstream ecosystem guarantees that this approach
will wipe out...
Kind regards,
Peter Kriens
On 18 Sep 2020, at 17:28, Lars Vogel <lars.vogel@xxxxxxxxxxx> wrote:
Why is API removed from Eclipse without bumping the major version
number?
I tried this once and we got furious feedback from the community that
is worse than anything else (see cross if you want to). People
maintain a max version and increasing the major version breaks them
completely So the PMC decided that planned deletions do not justify
major bumps.
Best regards, Lars
On Fri, Sep 18, 2020 at 5:11 PM Jonah Graham <jonah@xxxxxxxxxxxxxxxx>
wrote:
Sorry to rehash old questions - but I wasn't active when this was
first discussed. CDT has recently taken on this policy (but not used
it yet):
Why is API removed from Eclipse without bumping the major version
number? i.e the "In general, removing a deprecated API does NOT
cause the increase of the major version segment." in
https://wiki.eclipse.org/Eclipse/API_Central/API_Removal_Process
Thanks
Jonah
~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com
On Fri, 18 Sep 2020 at 09:43, 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#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@xxxxxxxxxxx
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@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
-- Eclipse Platform project co-lead
CEO vogella GmbH
Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
USt-IdNr.: DE284122352
Fax (040) 5247 6322, Email: lars.vogel@xxxxxxxxxxx, Web:
http://www.vogella.com
_______________________________________________
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
_______________________________________________
platform-dev mailing list
platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev