GEF 3.21 Release for Eclipse 2024-09

[azoitl]

This issue is used to track and coordinate the work for the GEF Classic 3.20.0 release to be contributed to the Eclipse 2024-03 release train. It shall serve as checklist as well as template for the upcoming release.

• [x] Create 3.21 Milestone
• [x] Update version number and target platforms:
  • [x] Update the version number of all features to 3.21.0
  • [x] Bump maintenance version number of all plugins
  • [x] Update the target platform for the API baseline to GEF Classic 3.20.0
  • [x] Update the pom file target platform checking to GEF Classic 3.20.0
  • [x] Update the development target platform to Eclipse 2024-06
• [x] 08.07.2024: Release 3.21.0 M1 for 2024-09 M1
  • [ ] create release record
• [x] 28.07.2024: Release 3.21.0 M2 for 2024-09 M2
• [ ] 19.08.2024: Release 3.21.0 M3 for 2024-09 M3
• [ ] 26.08.2024: Release 3.21.0 RC1 for 2024-09 RC1
• [ ] 02.09.2024: Release 3.21.0 for 2024-09 RC2
  • [ ] create R3_21_maintenance branch
• [ ] 11.09.2024: 2024-09 Release
  • [ ] tag release commit and mark it as release in Github, create release notes

[ptziegler]

Would it makes sense to do the contribution one or two days before Wednesday, from now on?

It's always a little risky for me when we do our contribution, because it's usually before GEF, even though we depend on it.

[azoitl]

Would it makes sense to do the contribution one or two days before Wednesday, from now on?

I'm rather open any date that helps you.

[ptziegler]

According to the wiki, GEF would be a "+1" project. If the Eclipse milestone is contributed on a Friday, we would then ideally contribute on the next Monday.

The Eclipse project has, for example a "+0" offset: they provide their bits on the first day of any given milestone or RC date. A project like EMF is "+1" meaning that they provide their bits one day after the milestone or RC date. This basically indicates that EMF "depends on" Eclipse; they use the extra time to pull down the milestone/RC bits from their dependencies and run tests before they contribute their own bits to the milestone/RC. There are "+2" and "+3" projects as well. i.e. BIRT is "+2" because it depends on a number of "+1" projects.

[azoitl]

Thx for looking up the process. When I started contributing GEF Classic to simrel I mostly just tired what worked. Should have been more carefull and read the docs. Updated the dates above accordingly. .

[azoitl]

2024-09 M1 contributed to simrel:

• https://download.eclipse.org/tools/gef/classic/milestone/S202407082024
• https://github.com/eclipse-simrel/simrel.build/pull/448

[ptziegler]

2024-09 M2 contributed to simrel:

• https://download.eclipse.org/tools/gef/classic/milestone/S202407281544
• https://github.com/eclipse-simrel/simrel.build/commit/ba9e60f0a400149da33a87c5d7dc44dfed9662f4

[azoitl]

2024-09 M3 contributed to simrel:

• https://download.eclipse.org/tools/gef/classic/milestone/S202408191842
• https://github.com/eclipse-simrel/simrel.build/commit/be5678e7c8c7d72325dbba09a75530f39b548773

[azoitl]

2024-09 RC2 contributed to simrel:

• https://download.eclipse.org/tools/gef/classic/milestone/S202409021815/index.html
• https://github.com/eclipse-simrel/simrel.build/pull/542

[azoitl]

Maintenance branch created: https://github.com/eclipse/gef-classic/tree/R3_21_maintenance

[azoitl]

Created 3.21.0 release build and contributed it to SimRel:

• https://download.eclipse.org/tools/gef/classic/release/3.21.0/
• https://github.com/eclipse-simrel/simrel.build/pull/559

The Github release with tag creation is prepared as well: https://github.com/eclipse/gef-classic/releases/tag/untagged-a998bacde8650f90bf1b

From my perspective we could go live with the release. This would also open master for the 3.22.0 work. @ptziegler any opinion on that?

[ptziegler]

Created 3.21.0 release build and contributed it to SimRel:

* https://download.eclipse.org/tools/gef/classic/release/3.21.0/

* [Contributing GEF 3.21.0 for Eclipse 2024-09 eclipse-simrel/simrel.build#559](https://github.com/eclipse-simrel/simrel.build/pull/559)

The Github release with tag creation is prepared as well: https://github.com/eclipse/gef-classic/releases/tag/untagged-a998bacde8650f90bf1b

From my perspective we could go live with the release. This would also open master for the 3.22.0 work. @ptziegler any opinion on that?

Go for it

[ptziegler]

This would also open master for the 3.22.0 work

In principle yes, but I usually like to keep any code changes to a minimum, during the week before the official SimRel release.

[azoitl]

This would also open master for the 3.22.0 work

In principle yes, but I usually like to keep any code changes to a minimum, during the week before the official SimRel release.

You have a point here. Lets wait then with any merges.

[azoitl]

Release is tagged and published: https://github.com/eclipse/gef-classic/releases/tag/R_3_21

Thanks to all contributors for making this possible!!!!

[ptziegler]

Looks like we ended up with two release records for the 3.21.0. I don't see any way to delete them from our side and have created a HelpDesk issue to hopefully sort this out: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/4987

[azoitl]

Ah fuck. I didn't notice. In the worst case we can change the title to 3.22.0 and use it for the next release. Maybe then I'll not do it in the last minute.