Preparation work for 4.35(2025-03) and open master for development

[MohananRahul]

This preparation work involves the following tasks. For previous issue please refer to #2274

• Create R4_34_maintenance branch #2554
• Update R4_34 maintenance branch with release version for 4.34+ changes #2556
• Move 4.34-I builds to R4_34_maintenance branch #2557
• Create new test jobs for 4.35 #2559
• Configure SWT build scripts for 4.35 #2562
• Splash Screen for 4.35 (2025-03) eclipse.platform#1634
• Create 4.35-I-builds repo #2564
• POM and product version changes for 4.35 release #2567
• Update product version number to 4.35 across build scripts #2568
• Move previous version to 4.34RC2 across build scripts
• Update version number in Mac's Eclipse.app for 4.35 #2577
• Clean forceQualifierUpdate files for doc bundles #2580
• Remove approved api list and build scripts for it as it's not used for years #2555
• Update builds and repo cleanup scripts for 4.35 #2578
• Create new I-build job for 4.35 release
• Update check composites script to verify 4.35 repositories #2586
• Update Comparator repo and eclipse run repo to 4.35-I-builds repo #2588
• Version bumps for 4.35 stream Clean in https://download.eclipse.org/eclipse/downloads/drops4/I20241126-0110/buildlogs/reporeports/reports/versionChecks.html
• Update previous release version to 4.34 GA across build scripts
• Update build calendar for platform 4.35 release
• Deploy ecj compiler from 4.34 GA and use it for 4.35 M1 build
• Update generic repos I-builds, Y-builds, P-builds to point to 4.35 repos

[HannesWell]

• Move previous version to 4.34RC2 across build scripts

@MohananRahul or @akurtakov can you tell if it would be possible to perform this step before creating all the version updated?
I.e. could we set the api- and comparator-baseline repo property previous-release.baseline to the current RC2-repo before the version updates are triggered, IIRC by creating the milestones? Then the workflows that perform the POM parent version updates could also immediately perform the version updates necessary in the bundle/feature projects because the project is changed the first time in a dev-cycle. See also eclipse-pde/eclipse.pde#1489 (comment)

Maybe this should also be included in #2565?
Which makes me wonder if the prepareRelease workflow should be triggered on workflow_dispatch, i.e. be executed manually. Then we could pass the next release as an input-argument plus the current RC2-repo to be used as baseline:

eclipse.platform.releng.aggregator/.github/workflows/prepareRelease.yml

Lines 2 to 4 in 63b98fe

	on:
	milestone:
	types: [created]

If that is the executed before the milestones are created all update-release workflows should then be able to succeed immediately, currently they are missing the parent-version in the repo because the PR mentioned above is currently also only created on milestone-creation too. And the workflow should be able to perform the necessary version bumps too.

@laeubi what do you think think?

[HannesWell]

@MohananRahul if you set the previous-release.baseline now it would still be possible to avoid manual version bumps by simply re-running the check-versions / Check and increment service versions workflow in all Update for release 4.35 PRs like eclipse-pde/eclipse.pde#1489.
IIRC currently the process is to await the first I-build and fix the comparator-errors manually afterwards?

[HannesWell]

Then we could pass the next release as an input-argument plus the current RC2-repo to be used as baseline:

At least the next version could also be computed by simply bumping the minor 'branding' version by one.
For the RC2 repo I currently have no smart way to compute it, except for looking it up in the SimRel contribution:
https://github.com/eclipse-simrel/simrel.build/blob/965a38026d3d81ae7a3ffe2957507a3d72af2698/ep.aggrcon#L3

[laeubi]

The prepare workflow is required to make the parent-pom available in the snapshot repository, the creation pf the PR triggers the deployment already so it can be used by other workflows a few seconds later.

Regarding the repositories, I already have suggested that we have ones with "stable" names so we can simply let this repo then point to whatever is required when (instead of changing the names all the time), e.g. currently the "new" comparator Ibuild repo is empty, and so we retain the previous one until the first successful ibuild then. Intead the "new" one could simply be a link to the "old" and will automatically be replaced by a new (successful) ibuild then.

Also the new 2024-12 could point to the 2024-12-RC2 unless there is a release so it could be used already before as a reference repository.

[HannesWell]

The prepare workflow is required to make the parent-pom available in the snapshot repository, the creation pf the PR triggers the deployment already so it can be used by other workflows a few seconds later.

Now that you say it, I remember that, it's because of

eclipse.platform.releng.aggregator/Jenkinsfile

Line 26 in 63b98fe

branch 'prepare_R*'

I don't recalls exactly how milestones are created. I assumed it was in a Jenkins-job were they are all created at once? And then even these few seconds could have been too late to resolve the new parent-pom, if all the jobs start at the same time in all repos.
But if they are all created manually and subsequently, then it should be fine.

While writing this and after some search I found a create-milestones job being mentioned in the release process. But from the doc, I have the impression it's hidden, so I cannot tell what it does exactly.