Y-builds are confused about 4.37 vs 4.38

[stephan-herrmann]

First build failure was noticed here: https://ci.eclipse.org/jdt/job/eclipse.jdt.core-run.javac-25/26/console

• composite repo https://download.eclipse.org/eclipse/updates/Y-builds already points to 4.38-Y-builds, which IMHO doesn't make sense before Java 25 GA / final freeze of BETA_JAVA25.
• for JDT/Core this got mitigated via Repair branch build by fixing repo url to 4.37-Y-builds eclipse-jdt/eclipse.jdt.core#4366 (reference explicit 4.37-Y-build repo)

Then Y-build itself failed: https://ci.eclipse.org/releng/job/YPBuilds/job/Y-build-4.37/49/console

• Could not find artifact org.eclipse:eclipse-platform-parent:pom:4.37.0-SNAPSHOT
• It seems that Y-build should now pull from 4.37-maintenance rather than master

Additionally the email notifying of this failure claimed a 4.38 Y-build:

[jdt-dev] 4.38 Y-Build: Y20250830-1000 - BUILD FAILED

The final Y-builds for Java 25 must be built from 4.37, not 4.38.

[HannesWell]

• composite repo https://download.eclipse.org/eclipse/updates/Y-builds already points to 4.38-Y-builds, which IMHO doesn't make sense before Java 25 GA / final freeze of BETA_JAVA25.

This was indeed changed intentionally in

• [RelEng] Unify composite repository creation #3215

and happens in

eclipse.platform.releng.aggregator/JenkinsJobs/Releng/prepareNextDevCycle.jenkinsfile

Lines 298 to 303 in a2780e4

	build job: 'Releng/modifyP2CompositeRepository', wait: true, propagate: true, parameters: [
	string(name: 'repositoryPath', value: "eclipse/updates/Y-builds"),
	string(name: 'repositoryName', value: "Eclipse latest Beta Java builds"),
	string(name: 'sizeLimit', value: '1'), // Clear all previous children
	string(name: 'add', value: "https://download.eclipse.org/eclipse/updates/${NEXT_RELEASE_VERSION}-Y-builds/"),
	]

I did this under the impression that Y-builds will just continue with the new stream and the P-build will use the latest stream (in this case 4.38) when it's published at the time of the Java-release.

But since the P-build is intended to be a patch for the old stream (in this case 4.37) you are absolutely right and it absolutely makes sense to continue the Y-build for the old stream until then (and to not merge the master into the BETA branch as I actually wanted to suggest).

But if https://download.eclipse.org/eclipse/updates/Y-builds should point to the old stream repo until the Java-release or not even if there is already a Y-build for the new stream is not yet clear to me. At least for I-builds that version-less links points to the latest available version.
Can you tell me who is using the download.eclipse.org/eclipse/updates/Y-builds repo and with what intended? I'm only aware of the P-build.

• for JDT/Core this got mitigated via Repair branch build by fixing repo url to 4.37-Y-builds eclipse-jdt/eclipse.jdt.core#4366 (reference explicit 4.37-Y-build repo)

Yes that's the right fix. As I think it's usually better to be as explicit as possible with references to repos, I would even say that it makes sense even to use always a specific repo. But this could also be generalized using:
<eclipse-p2-repo.url>https://download.eclipse.org/eclipse/updates/${releaseVersion}-Y-builds/</eclipse-p2-repo.url>

Then it doesn't need manual adjustments and it would still pick the right repository when the Y-build for the old stream runs on the maintenance branch.

Thinking about all your remarks again, I wonder if starting the Y-builds for the new stream makes sense at this point in time? I assume it only makes sense as soon as you have created the BETA-branches for a new Java realse doesn't it?
And should we run and continue the Y-build for the old stream on the maintenance branch now?
FYI, I changed the Y-build-4.37 build manually to run on the 4.37 maintenance branch every day (starting tomorrow) until the Java-release.

But I think it also doesn't make sense to run the Y-build for the new stream more often before a new Java release (as suggested in #3255 (comment)), but actually change the already existing build for the old stream?

Sorry if there are many question and not everything is running smoothly yet, but there are a lot of things to consider when automating all the release tasks. But once everything is implemented and discussed and it's clear what should run when, it should run smoothly.

[stephan-herrmann]

[...]
I did this under the impression that Y-builds will just continue with the new stream and the P-build will use the latest stream (in this case 4.38) when it's published at the time of the Java-release.

But since the P-build is intended to be a patch for the old stream (in this case 4.37) you are absolutely right and it absolutely makes sense to continue the Y-build for the old stream until then (and to not merge the master into the BETA branch as I actually wanted to suggest).

I should clarify that the combination of quarterly eclipse releases and semiannual Java releases implies an alternating scheme: with current numbering every Y release eventually targets an odd-numbered eclipse release. With these implications:

• when switching from even to odd (e.g., 4.36 -> 4.37) Y-builds should follow the version bump in master
• when switching from odd to even (4.37 -> 4.38) the Y-build needs to stay on the previous version until release

FWIW, freezing Y-builds at the same time as master is not an option, since at least one more change needs to be done right at Java GA: removal of beta-disclaimers.

But if https://download.eclipse.org/eclipse/updates/Y-builds should point to the old stream repo until the Java-release or not even if there is already a Y-build for the new stream is not yet clear to me. At least for I-builds that version-less links points to the latest available version. Can you tell me who is using the download.eclipse.org/eclipse/updates/Y-builds repo and with what intended? I'm only aware of the P-build.

While the marketplace advertises only the P-build repo, we do announce the Y-build repo along with the P-build one on mailinglists. Whether or not that's used much I can't tell. But surely we can announce the specific repo to avoid any confusion.

• for JDT/Core this got mitigated via Repair branch build by fixing repo url to 4.37-Y-builds eclipse-jdt/eclipse.jdt.core#4366 (reference explicit 4.37-Y-build repo)

Yes that's the right fix. As I think it's usually better to be as explicit as possible with references to repos, I would even say that it makes sense even to use always a specific repo. But this could also be generalized using: <eclipse-p2-repo.url>https://download.eclipse.org/eclipse/updates/${releaseVersion}-Y-builds/</eclipse-p2-repo.url>

We can see what fits us better, specific or generalized, thanks.

Thinking about all your remarks again, I wonder if starting the Y-builds for the new stream makes sense at this point in time? I assume it only makes sense as soon as you have created the BETA-branches for a new Java realse doesn't it?

yes.

And should we run and continue the Y-build for the old stream on the maintenance branch now? FYI, I changed the Y-build-4.37 build manually to run on the 4.37 maintenance branch every day (starting tomorrow) until the Java-release.

Thanks, I'll check the result.

But I think it also doesn't make sense to run the Y-build for the new stream more often before a new Java release (as suggested in #3255 (comment)), but actually change the already existing build for the old stream?

I'm not 100% sure which changes you are referring to, schedule or branch configuration?

[stephan-herrmann]

And should we run and continue the Y-build for the old stream on the maintenance branch now? FYI, I changed the Y-build-4.37 build manually to run on the 4.37 maintenance branch every day (starting tomorrow) until the Java-release.

Thanks, I'll check the result.

Can you see why all of yesterday's test builds failed:

• https://ci.eclipse.org/releng/job/YPBuilds/job/ep437Y-unit-linux-x86_64-java21/37/
• https://ci.eclipse.org/releng/job/YPBuilds/job/ep437Y-unit-linux-x86_64-java25/37/
• https://ci.eclipse.org/releng/job/YPBuilds/job/ep437Y-unit-macosx-aarch64-java21/37/
• https://ci.eclipse.org/releng/job/YPBuilds/job/ep437Y-unit-macosx-x86_64-java21/37/

OK, the macosx tests died of starvation, no available executor, but the other two did run, including invocation of actual testing, but then all we know is: it failed.

No test results also on https://download.eclipse.org/eclipse/downloads/drops4/Y20250901-1000/

OTOH, updating an old 4.37 I-build from https://download.eclipse.org/eclipse/updates/4.37-Y-builds/Y20250901-1000 works OK, and passes Java 25 related smoke tests.

[merks]

There were severe infrastructure problems last night, one of which prevented reading or writing from storage (download.eclipse.org):

https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/6581

That's likely related, but I can't be sure either.

[stephan-herrmann]

Randomly comparing some samples between

• 4.37 RC2: https://download.eclipse.org/eclipse/updates/4.37-I-builds/I20250828-0630/plugins/
• latest Y-build: https://download.eclipse.org/eclipse/updates/4.37-Y-builds/Y20250901-1000/plugins/

gives a few surprises:

• org.eclipse.help.base:
  • I: 4.5.200.v20250828-0630
  • Y: 4.5.200.v20250901-1000
• org.eclipse.pde:
  • I: 3.13.3200.v20250828-0630
  • Y: 3.13.3200.v20250901-1000
• similarly for org.eclipse.rcp, org.eclipse.sdk.examples, org.eclipse.sdk ...

Actually the Y-build should IMHO show timestamp 20250901-1000 only for any of the branched plugins below org.eclipse.jdt, right? Are the above exceptions an indication that these plugins already have changes in 4.37-maintenance? (Wouldn't that endanger a 4.37 re-spin, should it be needed?) Anyway, none of this seems dangerous for Y- and P-builds.

[merks]

Help base of course has not changed in the maintenance branch:

https://github.com/eclipse-platform/eclipse.platform/tree/R4_37_maintenance/ua/org.eclipse.help.base

Such timestamps indicate that master (4.38-I-builds) is being picked up.

Indeed no IU should have a timestamp higher than those of this build:

https://download.eclipse.org/eclipse/updates/4.37-I-builds/I20250828-0630/

Except of course the JDT patch bundles and features.

[stephan-herrmann]

Help base of course has not changed in the maintenance branch:

https://github.com/eclipse-platform/eclipse.platform/tree/R4_37_maintenance/ua/org.eclipse.help.base

Such timestamps indicate that master (4.38-I-builds) is being picked up.

Could this hiccup be related to this:

[2025-09-02T14:10:32.994Z] [WARNING] Your build is not self-contained! Project org.eclipse.platform:org.eclipse.help.base:eclipse-plugin:4.5.200-SNAPSHOT depends implicitly on reactor project org.eclipse.platform:org.eclipse.equinox.slf4j:eclipse-plugin:1.0.100-SNAPSHOT through target requirements eclipse-plugin:org.eclipse.jetty.http:12.1.0, eclipse-plugin:slf4j.api:2.0.17 that are not part of the reactor, offending dependency chain is eclipse-plugin:org.eclipse.help.base:4.5.200.qualifier (reactor project) --> eclipse-plugin:org.eclipse.equinox.http.jetty:3.9.500.v20250820-1640 (reactor project) --> eclipse-plugin:org.eclipse.jetty.http:12.1.0 (target dependency) --> eclipse-plugin:slf4j.api:2.0.17 (target dependency) --> eclipse-plugin:org.eclipse.equinox.slf4j:1.0.100.qualifier (reactor project)
[2025-09-02T14:10:32.994Z] [WARNING] Your build is not self-contained! Project org.eclipse.platform:org.eclipse.help.base:eclipse-plugin:4.5.200-SNAPSHOT depends implicitly on reactor project org.eclipse.platform:org.eclipse.equinox.slf4j:eclipse-plugin:1.0.100-SNAPSHOT through target requirements eclipse-plugin:org.eclipse.jetty.http:12.1.0, eclipse-plugin:slf4j.api:2.0.17 that are not part of the reactor, offending dependency chain is eclipse-plugin:org.eclipse.help.base:4.5.200.qualifier (reactor project) --> eclipse-plugin:org.eclipse.equinox.http.jetty:3.9.500.v20250820-1640 (reactor project) --> eclipse-plugin:org.eclipse.jetty.http:12.1.0 (target dependency) --> eclipse-plugin:slf4j.api:2.0.17 (target dependency) --> eclipse-plugin:org.eclipse.equinox.slf4j:1.0.100.qualifier (reactor project) --> eclipse-plugin:org.eclipse.equinox.slf4j.source:1.0.100.qualifier (reactor project)
[2025-09-02T14:10:32.994Z] [WARNING] The following implicit projects are not referenced: 
[2025-09-02T14:10:32.994Z] org.eclipse.platform:org.eclipse.equinox.slf4j:eclipse-plugin:1.0.100-SNAPSHOT

Anyway, aside from those few bundles with unexpected version today's Y-build looks OK-ish, and the corresponding P-build created from it is good (it only contains the "good" jdt parts 😄 ).

Thankfully also tests from Y-builds are back.