EPP 2026-03 M1

[merks]

The EPP Release Process

This guide contains the step-by-step process to complete an EPP release and assumes that you have an IDE provisioned using the Oomph setup.

Before copying this file to create a new issue titled EPP 2026-03 M1 with label endgame, update the names and versions, including those in this document.

• To update names and versions, edit org.eclipse.epp.releng.updater.Updater to set the values of MILESTONE, PLATFORM_VERSION, and possibly EXECUTION_ENVIRONMENT to the current appropriate values.
  • Use the Run toolbar button drop-down menu to launch the Update Versions launch configuration to apply all the necessary name and version changes.
  • Or use the Run toolbar button drop-down menu to launch the Open Issue launch configuration to apply all the necessary name and version changes, and to open a new properly-titled, properly-labeled issue; the body text is too long to automatically create the body of the issue, but that text is copied to the system clipboard, so you can use simply paste it into the body.

The individual releases are tracked with endgame issues on GitHub.

For each release (M1, M2, M3, RC1, RC2) an endgame ticket is created with the appropriate contents from the rest of this document:

EPP releases happen for each milestone and release candidate according to the Eclipse Simultaneous Release Plan

Steps at the beginning of each release cycle, i.e., before M1:

This checklist is only used once per release cycle.
Scroll down for the per-milestone/RC steps.

• Create new PMI entry
• Update splash screen (once per release cycle, hopefully done before M1). See detailed instructions.
• Archive old releases (two R releases should stay on download.eclipse.org) to archive.eclipse.org and remove non-R downloads.
  • This can be done through the web UI at https://download.eclipse.org/technology/epp/

Steps for all Milestones and RCs:

• Check for bad links to issues (and other things) especially in epp.website.xml.

• Make sure any outstanding reviews are progressing, e.g., create progress review, get PMC approval, etc.

  • Annual progress review is normally done in early June.

• Ensure that the CI build is green. Resolving non-green builds will require tracking down problems and incompatibilities across all Eclipse participating projects. The simrel-dev mailing list is a good place to start when tracking such problems.

• Check that packages containing incubating projects have that information reflected in Help -> About dialog. See near the end of the build output for a report of check-incubating.sh script.

  • This item is not currently done per milestone/release because for a while now all packages contain incubating components and until TM4E moves out of incubation this step is redundant.
  • The incubating indication should appear in feature.properties description, plugin.xml's product aboutText and about.properties blurb. In the past -incubation had to appear in the file name and (includes Incubating components) had to appear in packageMetaData. See Bug 564214 for documentation/votes on decision making.

• On RC1 check "new and noteworthy" version numbers. If any N&N are out of date, remove the N&N entries and notify the corresponding package maintainer.

  • Search for url= (notice the blank before url) in epp.website.xml to see which ones are contained in the different packages.
  • Remember that some of the features will release new versions together with the new Eclipse release. Therefore using the currently released version number may be wrong. Instead look up the feature version to be released with the release train.

• Synchronize the following - Remember to check the branch; these links are to master, but around RC2 master may be set up for the next release already.

  • Synchronize any changes to platform.product into all the epp.product files.
  • Synchronize any changes to platform.p2.inf into all the *.product/p2.inf files.
  • Synchronize any changes to platform's icons into icons root directory.

• Update the Last Recorded +1 in the email template which lists any package and platform +1s that have been received since the last update.

• Wait for announcement that the staging repo is ready on simrel-dev. An example announcement.

  • Update SIMREL_REPO in releng/org.eclipse.epp.config/parent/pom.xml if not done above.

• Update the build qualifiers to ensure that packages are all updated. See this gerrit for an example. Commit all other changes before this step because this step will automatically create a Git commit specifically for the forced qualifier changes. Use the External Tools toolbar drop-down menu to launch the Update Qualifiers launch configuration. This runs the setGitDate bash script. This script will make a local commit you need to push; do not amend it because the timestamp is relevant.

  • In some cases a respin/rebuild is needed and setGitDate needs to be run again. In that case you may need to manually add a minute or two to the applied timestamp in the script.

• Run a CI build that includes the above changes.

  • If the build fails, there may be the opportunity to continue the build rather than restart it.
  • If the build fails there may be the opportunity to continue the build rather than restart it. This is relatively underused option but enabled by the multi-step Jenkins build in the Jenkinsfile. For example, running the build with the previously successful steps commented out can produce a build.

• Disable the CI build so that the build results are not overwritten while doing the promotion. You can disable the project once it has fully started running; you don't have to wait for the build to finish.

• Check that there are no warnings in the console output. Especially look for warnings about failure to sign.

  • If warnings about signing occur that leave the DMG unsigned and the build does not fail, please reopen Bug 567916.

• Run the Notarize MacOSX Downloads CI job to notarize DMG packages on download.eclipse.org. This can be done after promotion if time is tight or the notarization fails repeatedly. See Bug 571669 for an example of failures.

• Check the build script output to make sure that the curl calls were successful,
  e.g., no curl: (92) HTTP/2 stream 0 was not closed cleanly: INTERNAL_ERROR (err 2) messages. If there is an error like the above, the .dmg file that is copied to download.eclipse.org is corrupt. Run notarize-prepare-to-redo to rename the -signed file back to -tonotarize and then re-run the notarize job job.

• Other notes about notarization

  • NOTE It seems perfectly normal that the notarize job needs to be run multiple times because many notarization attempts fail due to 500 and 000 response codes from the notarization server. See Bug 571669
  • NOTE Sometimes the notarization server has an error that causes a failure that requires Webmaster support. Error looks like "an existing transporter instance is currently uploading this package". To resolve, request assistance in Bug 573875 like what was done in Comment 11 of that bug. TODO: it may be possible to work around this error by always using a different random ID when doing the notarization.

• Sanity check the build for the following:

  • Download a package from the build's staging output.
  • Make sure filenames contain expected build name and milestone, e.g., 2026-03-M1.
  • Splash screen says the expected release name with no milestone, e.g., 2026-03.
  • Help -> About says the expected build name and milestone, e.g., 2026-03-M1.
  • From the Console, open the Host OSGi console and use ss -s INSTALLED to verify that there are no bundles failing to resolve.
  • The org.eclipse.epp.package.* features and bundles have the timestamp of the forced qualifier update or later.
  • Upgrade from previous release works. To test the upgrade an equivalent to the simrel release composite site needs to be done. Add the following software sites to available software, check for updates and then make sure stuff works. In particular check error log and that core features, e.g., JDT, Platform, have been upgraded.
    • https://download.eclipse.org/staging/2026-03/ - NOTE Use SIMREL_REPO if the staging repo has been updated since the SIMREL_REPO location was created.
    • https://download.eclipse.org/technology/epp/staging/repository/
    • https://download.eclipse.org/justj/epp/milestone/latest -
      This is needed when there is a new version of JustJ that is not also published as a release. For example, Java 21 between 2024-06 M1 and release date of 2024-06.
  • Verify that no non-EPP content is in the p2 repo (especially justj, update remove-justj-from-p2.xml if needed).

• Edit the Jenkins build.

  • Mark build as Keep forever.
  • Edit Jenkins Build Information and name it, e.g., 2026-03 M1.

• Run the Promote a Build CI job to prepare build artifacts and copy them to download.eclipse.org.

  • Optional - useful when testing changes to the promotion scripts: Run the build once in DRY_RUN mode to ensure that the output is correct before it is copied to download.eclipse.org.
  • This used to be done late in the day to try and reduce impact of adding dozens of GB on the download server and having all the mirrors start to pick it up right away. See epp-dev emails that led to this decision. However in 2024 the impact seems to no longer be a concern. This note is preserved until we know for sure there is no issue.
  • The DRY_RUN can be done earlier in the day and is a good way to increase the chance that the final promotion step will be successful.

• Run the Notarize MacOSX Downloads CI job to notarize DMG packages on download.eclipse.org if the promoted build was unstable.

• Update SIMREL_REPO to the staging repo so CI builds run against CI of SimRel, e.g., see this gerrit).

• Re-enable the CI build.

• Send email to epp-dev to request package maintainers test it. The email is templated in email.txt in the release directory.

  • NOTE For R build the release is initially published to a temporary location and then moved to the R directory later. Make a note in the email where the temporary location is.

• Archive old milestones/RCs so that they don't accumulate on the mirrors.

On all milestone/release days

This applies to all releases, i.e. M1, M2, M3, RC1 and R.
Everything except R is typically the Friday around 9:30am Ottawa time and the R is the following Wednesday sometime before 10am in coordination with the SimRel release engineer.

• Check that this worked: copy the composite*M1.jar files over the composite*.jar files in https://download.eclipse.org/technology/epp/packages/2026-03/ - this is done automatically with the EPP Make Visible job which is automatically triggered by SimRel's SimRel Make Visible Job.

24-48 Hours Before Final release day

• 24 Hours before Final release Make sure files are in final location to allow downloads to mirror.
  • Tag the release, e.g., 2026-03_R. Example command line: git tag --annotate 2026-03_R -m"2026-03 Release" 1b7a1c1af156e3ac57768b87be258cd22b49456b.
  • Run the Rename Provisional to Final CI job to rename the provisional release milestone to final directory. E.g., 2020-09/202009101200 -> 2020-09/R to match what is in release.xml - this only applies to downloads, not to packages.
    • Optional - useful when testing changes to the promotion scripts: Run the build once in DRY_RUN mode to ensure that the output is correct before it applies changes to download.eclipse.org.
  • Send an updated email to epp-dev informing that the provisional URL has been renamed to R.

On Final release day

These jobs should be completed by approximately 10am Ottawa time on release days.

• Run the Finalize Release CI job to create the "next" release and update the "latest" release as follows:
  • The current release needs to be promoted as "latest" under https://download.eclipse.org/technology/epp/packages/latest/. This should be a composite pointing to a specific https://download.eclipse.org/technology/epp/packages/yyyy-MM/.
  • The next release sub-directory needs to be created immediately.
    • When 2026-03 is released, a directory 2026-06 must be created with an empty p2 composite repository pointing to 2026-03 until M1.
    • On M1 release day this changes to a composite p2 repository with M1 content.
  • Optional - useful when testing changes to the promotion scripts:
    • Run the build once in DRY_RUN mode to ensure that the output is correct before it applies changes to download.eclipse.org.

[merks]

There are some strange "new" warnings like this:

10:01:34 [WARNING] The POM for org.eclipse.platform:org.eclipse.swt:jar:3.130.0 is invalid, transitive dependencies (if any) will not be available: 1 problem was encountered while building the effective model for org.eclipse.platform:org.eclipse.swt:3.130.0
10:01:34 [ERROR] 'dependencies.dependency.artifactId' for org.eclipse.platform:org.eclipse.swt.${osgi.platform}:jar with value 'org.eclipse.swt.${osgi.platform}' does not match a valid id pattern. @

This looks like an old approach that was used for publishing SWT to maven a while back. The current version of SWT is 3.133.0 so I'm not sure what's causing that warning.

[merks]

@jonahgraham

FYI, the notarization partially failed:

https://ci.eclipse.org/packaging/job/notarize-downloads/221/

So I am running it again.

I've already completed the sanity testing, and testing the Modeling package. So we just need for notarization to complete before promoting the build...

[merks]

@jonahgraham

I think maybe we are hosed because the failure is caused by libjansi.jnilib not being natively signed:

13:23:17 +179+ RESPONSE_RAW='{"uuid":"eb1a73a1-bb10-4317-9a41-fb91a3bfdb1f","notarizationStatus":{"status":"ERROR","message":"Notarization has failed on Apple notarization service","moreInfo":"Failed to notarize the requested file (status=Invalid). Error code=OptionalInt.empty. Reason: Optional.empty","log":"{\n "logFormatVersion": 1,\n "jobId": "2e8cb8ec-f0c9-47e4-944f-0a74af332316",\n "status": "Invalid",\n "statusSummary": "Archive contains critical validation errors",\n "statusCode": 4000,\n "archiveFilename": "eclipse-rcp-2026-03-M1-macosx-cocoa-x86_64-3332605346070037498.dmg",\n "uploadDate": "2026-01-08T12:04:37.132Z",\n "sha256": "931a610902bde7b121fba985d2d7f059eab3f4bd5fa55bb11d26cf077828871f",\n "ticketContents": null,\n "issues": [\n {\n "severity": "error",\n "code": null,\n "path": "eclipse-rcp-2026-03-M1-macosx-cocoa-x86_64-3332605346070037498.dmg/Eclipse.app/Contents/Eclipse/plugins/org.eclipse.m2e.maven.runtime.source_3.9.1101.20251020-1549.jar/jansi-2.4.2-sources-jar/org/fusesource/jansi/internal/native/Mac/x86/libjansi.jnilib",\n "message": "The binary is not signed.",\n "docUrl": "https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087721",\n "architecture": "i386"\n },\n {\n "severity": "error",\n "code": null,\n "path": "eclipse-rcp-2026-03-M1-macosx-cocoa-x86_64-3332605346070037498.dmg/Eclipse.app/Contents/Eclipse/plugins/org.eclipse.m2e.maven.runtime.source_3.9.1101.20251020-1549.jar/jansi-2.4.2-sources-jar/org/fusesource/jansi/internal/native/Mac/x86/libjansi.jnilib",\n "message": "The signature does not include a secure timestamp.",\n "docUrl": "https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087733",\n "architecture": "i386"\n },\n {\n "severity": "error",\n "code": null,\n "path": "eclipse-rcp-2026-03-M1-macosx-cocoa-x86_64-3332605346070037498.dmg/Eclipse.app/Contents/Eclipse/plugins/org.eclipse.m2e.maven.runtime.source_3.9.1101.20251020-1549.jar/jansi-2.4.2-sources-jar/org/fusesource/jansi/internal/native/Mac/arm64/libjansi.jnilib",\n "message": "The binary is not signed with a valid Developer ID certificate.",\n "docUrl": "https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087721",\n "architecture": "arm64"\n },\n {\n "severity": "error",\n "code": null,\n "path": "eclipse-rcp-2026-03-M1-macosx-cocoa-x86_64-3332605346070037498.dmg/Eclipse.app/Contents/Eclipse/plugins/org.eclipse.m2e.maven.runtime.source_3.9.1101.20251020-1549.jar/jansi-2.4.2-sources-jar/org/fusesource/jansi/internal/native/Mac/arm64/libjansi.jnilib",\n "message": "The signature does not include a secure timestamp.",\n "docUrl": "https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087733",\n "architecture": "arm64"\n },\n {\n "severity": "error",\n "code": null,\n "path": "eclipse-rcp-2026-03-M1-macosx-cocoa-x86_64-3332605346070037498.dmg/Eclipse.app/Contents/Eclipse/plugins/org.eclipse.m2e.maven.runtime.source_3.9.1101.20251020-1549.jar/jansi-2.4.2-sources-jar/org/fusesource/jansi/internal/native/Mac/x86_64/libjansi.jnilib",\n "message": "The binary is not signed.",\n "docUrl": "https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087721",\n "architecture": "x86_64"\n },\n {\n "severity": "error",\n "code": null,\n "path": "eclipse-rcp-2026-03-M1-macosx-cocoa-x86_64-3332605346070037498.dmg/Eclipse.app/Contents/Eclipse/plugins/org.eclipse.m2e.maven.runtime.source_3.9.1101.20251020-1549.jar/jansi-2.4.2-sources-jar/org/fusesource/jansi/internal/native/Mac/x86_64/libjansi.jnilib",\n "message": "The signature does not include a secure timestamp.",\n "docUrl": "https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087733",\n "architecture": "x86_64"\n }\n ]\n}\n"}}

Of course one wonders what are native libraries doing in jansi-2.4.2-sources-jar...

I suspect this problem is new because now some products install all available sources which in this case includes also the sources for org.eclipse.m2e.maven.runtime.source... 😢

[merks]

@jonahgraham

The only idea I have to avoid this to exclude that source bundle from the aggregation. I'm a that it's even useful in any way shape or form, and I doubt the native libraries will be removed from the nested jars anytime soon (which also looks stupid).

[jonahgraham]

@merks I have seen your messages and I am looking into this now - its been a while since we had a notarization issue (thankfully)

[jonahgraham]

jnilibs in jansi has been a problem in the past and m2e started signing them in eclipse-m2e/m2e-core#591 (upstream issue is fusesource/jansi#232)

[merks]

I've concluded that its a valid problem that absolutely prevents notarization. I think it's new because this source bundle was not in any product before, but now it is. I believe the binary bundle's nested jars are notarized (hence no problems before) but no one knew that the sources had these binary libraries as well and hence they are not signed in the nested jar of the source bundle, but that hasn't been a problem until now.

The only quick and dirty solution seems to be to exclude it from release train repository, which is possible via

eclipse-cbi/p2repo-aggregator@039cb50

But it turns out that the m2e.sdk includes source features that transitively require the runtime source bundle, so I will need to remove the m2e.sdk feature temporarily from SimRel.

Or we can ship M1 with some of the package unnotarized and rely on @HannesWell @laeubi to fix something for M2; the option to excluded this a specific source bundle is now available for the aggregator in any case.

Another solution is to build the product without source for M1...

Best to make a decision sooner rather than later to get the ball rolling...

[jonahgraham]

Ship M1 without them notarized (just tar.gz for those macOS). We have done that in the past

[merks]

That's certainly by far the least amount of work. I recall some exceptional circumstances in the past. 👍

For M2 I expect that m2e will stop having/using/providing source features and even if the problem in nested jars of the runtime.source bundle remain we can easily exclude those from aggregation into the train repository.

I will continue with the remaining steps of this issue then.

I have some exciting additional automation working for sanity test parts, so I'd like to get those committed today as well.