Meeting notes for Planning Council 2025-03-05

[HeikoKlare]

Discussed Topics

• Status 2025-03
• Change in release policy (Java version support) for 2025-09 release (JDK 25)? (Follow-up from 2024-11 meeting)
• Badges proposals: https://gitlab.eclipse.org/eclipse-wg/ide-wg/community/-/issues/71

Formatted Document Preview

https://github.com/HeikoKlare/eclipse-simrel-.github/blob/planning-council-2025-03-05/wiki/Planning_Council/2025-03-05.md

[tfroment]

+1 on release policy, this is really awaited by many people.

• Can we have a very quick discussion on badges proposals: https://gitlab.eclipse.org/eclipse-wg/ide-wg/community/-/issues/71

[merks]

Do we have any data about how many people or the % of the people? I would have assumed that the majority of the developers use LTS versions while a very small minority (perhaps a vocal minority) would be interested in immediately moving to use the latest Java languages features. Of course I have no statistical basis for that assumption, but probably we have no data at all.

In any case, I would expect that those who wish to have the latest and greatest immediately, despite the higher likelihood of bugs and even regressions, will be well served by easily updating to that latest version as soon as it's available:

eclipse-oomph/oomph#134 (comment)

And the rest of the users can stay in a stable, well-tested stable basis if they so choose.

I would be significantly concerned with respect to the logistics of managing how JDT develops beta features on a separate branch, how that is merged and tested with sufficient runway to be of release quality for all consumers, on some schedule that follows a Java release which I suppose we assume is etched in stone. It sounds to me much more risky. Moreover it's a risk that's incurred by all the users, perhaps to the benefit of a small number of them and perhaps to the detriment of far too many of them.

[HeikoKlare]

Maybe the short description regarding the Java release policy was a bit misleading. If I am not mistaken, in the discussion in November we concluded that we want to discuss about the possibility for changes regarding the release policy based on potential improvements in terms of separation of Java runtime and compiler support made for JDT until then. This is not about changing the overall release policy regarding full support of new JDK versions in JDT.
We explicitly scheduled it as a follow-up discussion for now as it would be beneficial for the next LTS release in September (for non-LTS releases I fully agree with Ed that it will probably not be that relevant).

To recap, here is the relevant part of the protocol from November:

• Consider Java releases for schedule?
  • we could make our releases later to avoid patch releases for new Java version
  • challenge: very limited time to come up with Java release and features frozen late in Java development cycle → patch policy relieves us from pressure to deliver Java version support for Eclipse release (reduces risk)
• Independence of Java compiler and runtime support
  • Some of the Java runtime support, constants will be available only with the "complete" Java Support after the official Java release - this makes it difficult for the softwares that consume some of these changes early to adapt to the latet Java releases.
  • one could separate Java runtime support (to be shipped with Eclipse release) from compiler support (to be shipped as patch) → make runtime support available early, e.g., for PDE
  • we should try to approach changes in these policies in 2025