[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-dev] Recent API Removal breaks clients
|
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
