| Re: [eclipse-dev] eclipse sdk v5 ❤ |
Hi,
> * an IDE that is lightweight and fast. why this is needed? because all the competing IDEs are light and fast. are they more attractive because they are light and fast? yes. This requires breaking changes with a major version.
Can you elaborate what "breaking changes" would be needed for this? It is already possible to remove plugins from the default packages (e.g. Mylyn) to make parts of it faster and make some changes to the default perspectives for a more "lightweight" experience (that is just a matter of willingness). When it comes to performance, there are probably a lot of optimizations that could be done without breaking compatibility (which haven't been done yet). Furthermore (on the "lightweight" side), it may also be possible to refactor some things into different OSGi bundles if most users don't need a part of the functionality and keep the existing bundle with the extracted bundles as dependencies to preserve compatibility.
> * an IDE that AI assistants can easily integrate into. major LLM SDKs build first class integrations for other IDEs. AI assisted development is the new baseline and when we don't have a credible AI story. developers switch IDEs and do not return. and we can't do modern AI integration cleanly onto a 20 year old plugin architecture. This requires breaking changes with a major version.
I think the Eclipse Agents (https://github.com/eclipse-agents/eclipse-agents/) proposal/project already does that but there isn't sufficient interest to actually put it forward. I don't see any reason why any of this would require any breaking changes.
What exactly are the APIs you need to make breaking changes for and how "breaking" are they? How would you get most of the existing plugins working with v5 (including ones that may not be maintained)? Could you point out what deprecated APIs (or design decisions) are actually causing the issues you mentioned? From what I can see, both of the issues are things that could be addressed without major breaking changes but I don't feel like having a v5 in sight will make people more willing to implement these things. I think the main problem is not being bound by staying on v4 but by the development capacity for improvements. And if minor removals are needed, these are probably still possible.
That being said, there are a lot of people who don't want AI assistents at all on their systems. Building the tools they use around AI assistents would likely cause annoyances for those people.
Yours,
Daniel
the previous discussion on the topic here: https://www.eclipse.org/lists/eclipse-dev/msg12346.html (not sure how to link these two)
thanks Aleks for the links. the incremental API removal policy looks good. i did some random search and found APIs that are 15+ years old living with deprecated tag. if the policy is working smoothly, why are some of those APIs still present? i guess the answer is API removal is hard when they are fused into the core design of the IDE.
and that was just one item from the list of concerns (breaking changes accumulating over time, exponentially harder for future migrations, introduction of awkward workarounds...) i raised.
to me, what are the compelling case for v5? what are things that cannot be developed without breaking v4?
* an IDE that is lightweight and fast. why this is needed? because all the competing IDEs are light and fast. are they more attractive because they are light and fast? yes. This requires breaking changes with a major version.
* an IDE that AI assistants can easily integrate into. major LLM SDKs build first class integrations for other IDEs. AI assisted development is the new baseline and when we don't have a credible AI story. developers switch IDEs and do not return. and we can't do modern AI integration cleanly onto a 20 year old plugin architecture. This requires breaking changes with a major version.
Thanks,Gireesh Punathil
From: Александър Куртаков <akurtakov@xxxxxxxxx>
Date: Wednesday, 27 May 2026 at 2:00 PM
To: General development mailing list of the Eclipse project. <eclipse-dev@xxxxxxxxxxx>
Cc: GIREESH PUNATHIL <gpunathi@xxxxxxxxxx>
Subject: [EXTERNAL] Re: [eclipse-dev] eclipse sdk v5 ❤️
_______________________________________________ eclipse-dev mailing list eclipse-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse-dev