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.vo...@vogella.com> 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 <jo...@kichwacoders.com> 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 <akurt...@redhat.com> wrote:
On Fri, Sep 18, 2020 at 12:30 PM Aleksandar Kurtakov <akurt...@redhat.com>
wrote:
On Fri, Sep 18, 2020 at 11:27 AM Wim Jongman <wim.jong...@gmail.com> 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@eclipse.org
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@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
--
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.vo...@vogella.com, Web: http://www.vogella.com
_______________________________________________
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
_______________________________________________
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
