GEF Classic 3.26 Release for Eclipse 2025-12
This issue is used to track and coordinate the work for the GEF Classic 3.26.0 release to be contributed to the Eclipse 2025-12 release train. It shall serve as checklist as well as template for the upcoming release.
- [x] Create 3.26 Milestone
- [x] Update version number and target platforms:
- [x] Update the version number of all features to 3.26.0
- [x] Bump maintenance version number of all plugins
- [x] Update the target platform for the API baseline to GEF Classic 3.25.0
- [x] Update the pom file target platform checking to GEF Classic 3.25.0
- [x] Update the development target platform to Eclipse 2025-12
- [x] 06.10.2025: Release 3.26.0 M1 for 2025-12 M1
- [x] create release record
- [x] 27.10.2025: Release 3.26.0 M2 for 2025-12 M2
- [x] 17.11.2025: Release 3.26.0 M3 for 2025-12 M3
- [ ] 24.11.2025: Release 3.26.0 RC1 for 2025-12 RC1
- [ ] 01.12.2025: Release 3.26.0 for 2025-12 RC2
- [ ] create R3_26_maintenance branch
- [ ] 10.12.2025: 2025-12 Release
- [ ] tag release commit and mark it as release in Github, create release notes
Master branch is open and ready for 3.26 contributions.
@azoitl What should we do about #805? I think it would be beneficial to have this included for the M1. I've already prepared a fix for the Zest tests, but don't have a solution for the Draw2D failures. Here I'm tempted to revert the enablement of the "advanced mode" in the FigureUtilities class and track that issue separately.
@ptziegler the more we have in M1 the better. However the last weeks I didn't find enough time to full go through all the changes. So I would rely on your assessment. But splitting sounds like a good approach.
Then let's merge everything. I think especially with such a delicate feature, early feedback will be invaluable. And if there are issues, people can always opt-out and get the original functionality.
Could you do the M1 later today?
Sure. I'll trigger the job once everything is merged.
M1 has been contributed:
https://download.eclipse.org/tools/gef/classic/milestone/S202510061831 https://github.com/eclipse-simrel/simrel.build/commit/9ff79e835aae1c0ed730f8e21582cc5f4ba117c3
Release record: https://projects.eclipse.org/projects/tools.gef/releases/gef-classic-3.26.0
Respin of the M1: https://download.eclipse.org/tools/gef/classic/milestone/S202510081740 https://github.com/eclipse-simrel/simrel.build/commit/358fee9f756a92e6ad74eb05656555b912c9ad9f
M2 has been contributed:
- https://download.eclipse.org/tools/gef/classic/milestone/S202510280640
- https://github.com/eclipse-simrel/simrel.build/commit/c4118f0041ed917d8e9fa141c8bbebbb274a2db6
M2a has been contributed, containing the fix for https://github.com/eclipse-gef/gef-classic/issues/831: https://download.eclipse.org/tools/gef/classic/milestone/S202510291753 https://github.com/eclipse-simrel/simrel.build/commit/5e8a8014ddb2c2bbe03c2462af0858d015283639
Fixed date of M3 as I accidentally put it a week to early.
Contribute early and contribute often. It's not a problem. 😁
I would try to target the "new" M3 for tomorrow, so that we still have a chance to include #850 and #834.
I would try to target the "new" M3 for tomorrow, so that we still have a chance to include #850 and #834.
Thx for taking care of all these scaling issues. I somehow lost track and I'm a bit busy with other stuff.
I did a respin of the M3 just now. Hopefully next week I'll get some time to test it with our product, just in case something else comes up that needs to be fixed before the RC1/RC2.
https://download.eclipse.org/tools/gef/classic/milestone/S202511181945 https://github.com/eclipse-simrel/simrel.build/commit/728b06928de8c8d362444c61e91b96d9457e0e2d
I'm really not comformtable with the current state of the HiDPI implementation and I'm not sure if it's a good idea to let it out into the wild, in its current state. Ideally, I'd like to be able to fully restore the original behavior by setting draw2d.enableAutoscale and I'm even playing with the idea of having it be disabled by default again.
We're three weeks before the release and I really don't want to merge last-minute changes, even though we're already in code-freeze.
The RC1 has just been contributed: https://github.com/eclipse-simrel/simrel.build/commit/a22ead749c0e981c7176b49f8b046786c28fc395 https://download.eclipse.org/tools/gef/classic/milestone/S202511241935
@azoitl Is there anything still open? Otherwise I would trigger the RC2 build later this evening.
@azoitl Is there anything still open? Otherwise I would trigger the RC2 build later this evening.
@ptziegler I don't think so. All that I noticed is something better to be done for 3.27.0 M1
The RC2 has been built and submitted: https://github.com/eclipse-simrel/simrel.build/commit/59599b56057c45deeb913549f19071ad3c3e85e8 https://download.eclipse.org/tools/gef/classic/milestone/S202512022008
I've also taken the liberty to already create the release branch because I don't expect a respin until Thursday.
@ptziegler should we create the relase from the current state and submit it to simrel so that we can start merging the new things going on?
@azoitl No objections from my side. There are quite a lot of PRs that have accumulated over the past few days and I think the weekend might be a good time to prepare everything for the next release cycle.