Re: [eclipse-dev] eclipse sdk v5 ❤️

[GIREESH PUNATHIL <gpunathi@xxxxxxxxxx>]

thanks Aleks, i agree with the ground realities on less interest and no show on major features.

thinking of it, i see a chicken-egg sort of issue here: if we say:

 - "show up with a working demo of v5, then we will consider it.”, 

 - this would need architectural shifts

 - which requires months of co-ordinated effort

 - which, requires a support from the project leadership

 - which in turn circles back to open-ness on v5 scale features.

so i guess if we make an explicit statement like:

 - these are the architectural areas we believe need v5 level changes.

 - we don't have band with to spend on it ourselves

 - but we are committed to review and accept the changes if folks are willing to contribute

 - we can guarantee that we won't reject those just because they break backwards.

that would probably attract folks to pick up items and contribute. WDYT?

Thanks,

Gireesh Punathil

From: Александър Куртаков <akurtakov@xxxxxxxxx>
Date: Wednesday, 27 May 2026 at 9:25 PM
To: GIREESH PUNATHIL <gpunathi@xxxxxxxxxx>
Cc: General development mailing list of the Eclipse project. <eclipse-dev@xxxxxxxxxxx>
Subject: [EXTERNAL] Re: [eclipse-dev] eclipse sdk v5 ❤️

This Message Is From an Untrusted Sender

You have not previously corresponded with this sender.

Report Suspicious

 

On Wed, May 27, 2026 at 4:37 PM GIREESH PUNATHIL <gpunathi@xxxxxxxxxx> wrote:

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.

API removal requires one to clean up Eclipse SDK from usages of the API to be removed. Long story short - no one showed up to do the work thoroughly and complete.

 

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.

IMO the problem is not that there is no v5 (or plan for it) . The problem is that no one showed up to do some work that would justify having Eclipse v5. If/when someone shows up with concrete proposals he/she has in some demo working form and pinpoint exact problems in current APIs and shows a better way how smth should be done - I can see many supporting such an initiative.

Doing breaking changes for the sake of breaking things will do only bad (break existing plugins) for no gain (until such is clearly shown).

 

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 ❤️

This Message Is From an Untrusted Sender

You have not previously corresponded with this sender.

Report Suspicious

 

On Wed, May 27, 2026 at 10:34 AM GIREESH PUNATHIL via eclipse-dev <eclipse-dev@xxxxxxxxxxx> wrote:

i want to resume this discussion , but i lost the old mail thread (more than an year old), hope the title will help sync with the thread in the email discussion archive.

what do people think about moving to v5?

i strongly support this.

What would be the driving new feature/api/design for v5? If such a development is happening yet - it would better be shared with the community so more context could be put in the discussion. At least I'm not aware of anything like that.

 

if backward incompatibility and ecosystem breakage is a concern, the one time manual efforts for migration is now drastically reduced with several AI tools available.

on the other hand, if we don't move, breaking changes accumulate over time, making it exponentially harder for future migrations, while code gets filled with awkward workarounds, old APIs still linger while better designs are possible....

That's totally not the case:

* Old APIs can be removed incrementally with 2 years deprecation period as per https://eclipse.dev/eclipse/markdown/?file=eclipse-platform/eclipse.platform/master/docs/Eclipse_API_Central_Deprecation_Policy.md

* Old APIs are getting deprecated - e.g. https://download.eclipse.org/eclipse/downloads/drops4/R-4.39-202602260420/apitools/deprecation/apideprecation.html for 4.39 deprecations and the javadoc clearly shows terminally deprecated APIs https://help.eclipse.org/latest/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fapi%2Fdeprecated-list.html&anchor=for-removal

* Old APIs are getting removed - e.g. https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/master/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/porting/removals.html , https://github.com/eclipse-platform/eclipse.platform.swt/pull/3127, .....

Are you actually looking for the "marketing" effect of v5? I ask as so far I fail to spot any technical reason for v5.

 

Thanks,

Gireesh Punathil

_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse-dev