eclipse-packaging · merks · Jul 11, 2025 · Jul 11, 2025
diff --git a/RELEASING.md b/RELEASING.md
@@ -1,6 +1,7 @@
 # The EPP Release Process
 
 This guide contains the step-by-step process to complete an EPP release.
+The guide assumes that you have an IDE provisioned using the [Oomph setup](CONTRIBUTING.md#create-an-eclipse-development-environment).
 
 The individual releases are tracked with [endgame](https://github.com/eclipse-packaging/packages/labels/endgame) issues on GitHub issues.
 For each release (M1, M2, M3, RC1, RC2) an endgame ticket is created with the appropriate contents from the rest of this document:
@@ -15,35 +16,37 @@ Scroll down for the per-milestone/RC steps.
 - [ ] Create new [PMI entry](https://projects.eclipse.org/projects/technology.packaging)
 - [ ] Update splash screen (once per release cycle, hopefully done before M1).
       See detailed [instructions](https://github.com/eclipse-packaging/packages/blob/master/packages/org.eclipse.epp.package.common/splash/INSTRUCTIONS.md).
-- [ ] When the year changes, e.g., between 2025-12 and 2026-03 releases,
-      an update of the copyright year is required with a very smart search&replace.
-      A good replacement is `/, 2021/, 2022/` excluding `*.svg`
-- [ ] In addition to the "Update Name" step on every M and RC,
-      the whole version string is updated, including platform version; this is a large change including the following:
-  - [ ] pom.xml
-  - [ ] feature.xml
-  - [ ] MANIFEST.MF
-  - [ ] epp.website.xml
-    - [ ] `NewAndNoteworthy` entry needs updating which has a slightly different pattern than other versions.
-  - [ ] epp.product
-  - [ ] p2.inf
-  - [ ] epp.p2.inf
-  - [ ] Jenkinsfile (SimRel triggering URL)
-  - [ ] `2025-12` -> `2026->03` part
-  - [ ] `4.38` -> `4.39` part
+- [ ] This step is automated along with the following step.
+      ~When the year changes, e.g., between 2025-12 and 2026-03 releases, an update of the copyright year is required with a very smart search&replace. A good replacement is `/, 2021/, 2022/` excluding `*.svg`~
+- [ ] The `Update Name` step below is now fully automated.
+      ~The following manual steps can be skipped and simply document what the automation does.
+      Previously on every M and RC,
+      the whole version string was manually updated,
+      including the platform version;
+      this large automated change includes updating the following:~
+  - [ ] ~pom.xml~
+  - [ ] ~feature.xml~
+  - [ ] ~MANIFEST.MF~
+  - [ ] ~epp.website.xml~
+    - [ ] ~`NewAndNoteworthy` entry needs updating which has a slightly different pattern than other versions.~
+  - [ ] ~epp.product~
+  - [ ] ~p2.inf~
+  - [ ] ~epp.p2.inf~
+  - [ ] ~Jenkinsfile (SimRel triggering URL)~
+  - [ ] ~`2025-12` -> `2026->03` part~
+  - [ ] ~`4.38` -> `4.39` part~
   - [ ] Adding the previous past release explicitly to list in release.xml, located in promote-a-build.sh
 - [ ] 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 Bugzilla (and other things) especially in `epp.website.xml`
-- [ ] Make sure any outstanding [reviews](https://projects.eclipse.org/projects/technology.packaging/governance) are progressing,
-      e.g., create progress review, get PMC approval, etc.
+- [ ] Check for bad links to issues (and other things) especially in `epp.website.xml`.
+- [ ] Make sure any outstanding [reviews](https://projects.eclipse.org/projects/technology.packaging/governance) 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](https://ci.eclipse.org/packaging/job/epp/job/master/) is green.
       Resolving non-green builds will require tracking down problems and incompatibilities across all Eclipse participating projects.
-      [simrel-dev](https://accounts.eclipse.org/mailing-list/simrel-dev) mailing list is a good place to start when tracking such problems.
+      The [simrel-dev](https://accounts.eclipse.org/mailing-list/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.
@@ -58,43 +61,49 @@ Scroll down for the per-milestone/RC steps.
         Therefore using the _currently_ released version number may be wrong.
         Instead lookup the feature version [to be released with the release train](https://projects.eclipse.org/releases/).
 - [ ] Synchronize the following - Remember to check branch, these links are to master, but around RC2 master may be setup for next release already.
-  - [ ] Synchronize any changes to 
-        [platform.product](https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/master/eclipse.platform.releng.tychoeclipsebuilder/eclipse.platform.repository/platform.product)
-        into all the `epp.product` files.
-  - [ ] Synchronize any changes to
-        [platform.p2.inf](https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/master/eclipse.platform.releng.tychoeclipsebuilder/eclipse.platform.repository/platform.p2.inf)
-        into all the `*.product/p2.inf` files.
-  - [ ] Synchronize any changes to
-        [platform's icons'](https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/tree/master/eclipse.platform.releng.tychoeclipsebuilder/eclipse.platform.repository/icons)
-        into `icons` root directory.
-- [ ] Update name of the release in strings with a "smart" global find&replace.
+  - [ ] Synchronize any changes to [platform.product](
+        https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/master/eclipse.platform.releng.tychoeclipsebuilder/eclipse.platform.repository/platform.product
+        ) into all the `epp.product` files.
+  - [ ] Synchronize any changes to [platform.p2.inf](
+        https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/master/eclipse.platform.releng.tychoeclipsebuilder/eclipse.platform.repository/platform.p2.inf
+        ) into all the `*.product/p2.inf` files.
+  - [ ] Synchronize any changes to [platform's icons](
+        https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/tree/master/eclipse.platform.releng.tychoeclipsebuilder/eclipse.platform.repository/icons
+        ) into `icons` root directory.
+- [ ] To update names an version, edit [org.eclipse.epp.releng.updater.Updater](
+      releng/org.eclipse.epp.config/org.eclipse.epp.releng.updater/src/org/eclipse/epp/releng/updater/Updater.java
+      ) to set the value of `MILESTONE`, `PLATFORM_VERSION`, and possibly `EXECUTION_ENVIRONMENT` to the current appropriate values.
+     - Use `Run` tool-bar button drop-down menu to launch the `Update Versions` launch configuration
+      to apply all the necessary name and version changes.
+- [ ] ~Due to automation, this step can now be skipped.~
+      ~Update name of the release in strings with a "smart" global find&replace.
       _Be careful on M3 that the replace did not match the Eclipse project name M2E!_
       See [this](https://github.com/eclipse-packaging/packages/commit/d7c1fc0b355185ceb9635fbc12a4af81e2295a91/) for an example.
-      Use commit message like `[releng] Prepare repo for 2025-09 M1`.In particular, check the following::
-  - **TODO can this be automated**
+      Use commit message like `[releng] Prepare repo for 2025-09 M1`.In particular, check the following::~
+  - ~**TODO can this be automated**
     On M1 add the M1 qualifier, e.g., `2025-06-R` -> `2025-09-M1`, on RC2 set it to `R` the qualifier, e.g., `2025-09-RC1` -> `2025-09-R`.
-    **Except** for `eclipse.simultaneous.release.name` which should go from `2025-06 (4.36.0)` -> `2025-09 M1 (4.37.0 M1)` on M1 and `2025-09 RC1 (4.37 RC1)` -> `2025-09 (4.37.0)` on RC2
-  - [ ] `packages/*/epp.website.xml` for `product name=` line.
-  - [ ] `RELEASE_NAME`, `PREV_RELEASE_NAME`, `NEXT_RELEASE_NAME`, `RELEASE_MILESTONE`, `RELEASE_DIR`, `SIMREL_REPO`,  variables in parent pom `releng/org.eclipse.epp.config/parent/pom.xml`
-    - `SIMREL_REPO` should be updated to the URL published in the email to cross-project-issues announcing SimRel repo is ready for EPP build.
-  - [ ] **TODO can this part below be automated**
-    - See comment in the pom.xml file around `eclipse.simultaneous.release.name`.
-    - On R build, for `eclipse.simultaneous.release.name` remove qualifier,
-      i.e., it should be `2025-09 (4.37.0)`.
-    - On M1 build add the qualifier back in, for `eclipse.simultaneous.release.name`,
-      i.e., it should be `2025-09 M1 (4.37.0 M1)`
-- [ ] Update the 
-      [Last Recorded +1 in the email template](https://github.com/eclipse-packaging/packages/blob/master/releng/org.eclipse.epp.config/tools/upload-to-staging.sh)
-      which any package and platform +1s that have been received since the last update.
+    **Except** for `eclipse.simultaneous.release.name` which should go from `2025-06 (4.36.0)` -> `2025-09 M1 (4.37.0 M1)` on M1 and `2025-09 RC1 (4.37 RC1)` -> `2025-09 (4.37.0)` on RC2.~
+  - [ ] ~`packages/*/epp.website.xml` for `product name=` line.~
+  - [ ] ~`RELEASE_NAME`, `PREV_RELEASE_NAME`, `NEXT_RELEASE_NAME`, `RELEASE_MILESTONE`, `RELEASE_DIR`, `SIMREL_REPO`,  variables in parent pom `releng/org.eclipse.epp.config/parent/pom.xml`~
+    - ~`SIMREL_REPO` should be updated to the URL published in the email to cross-project-issues announcing SimRel repo is ready for EPP build.~
+  - [ ] ~**TODO can this part below be automated**~
+    - ~See comment in the pom.xml file around `eclipse.simultaneous.release.name`.~
+    - ~On R build, for `eclipse.simultaneous.release.name` remove qualifier,
+      i.e., it should be `2025-09 (4.37.0)`.~
+    - ~On M1 build add the qualifier back in, for `eclipse.simultaneous.release.name`,
+      i.e., it should be `2025-09 M1 (4.37.0 M1)`~
+- [ ] Update the [Last Recorded +1 in the email template](
+      https://github.com/eclipse-packaging/packages/blob/master/releng/org.eclipse.epp.config/tools/upload-to-staging.sh
+      ) which 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](https://accounts.eclipse.org/mailing-list/simrel-dev).
       An [example announcement](https://www.eclipse.org/lists/simrel-dev/msg00032.html).
   - [ ] 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](https://git.eclipse.org/r/#/c/161075/) for an example.
-      To do this run `releng/org.eclipse.epp.config/tools/setGitDate`
-      ([link](https://github.com/eclipse-packaging/packages/blob/master/releng/org.eclipse.epp.config/tools/setGitDate))
-      script.
-      This script will make a local commit you need to push, do not amend it because the timestamp is relevant.
+      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` tool-bar drop-down menu to launch the `Update Qualifiers` launch configuration.
+      This runs the [setGitDate](releng/org.eclipse.epp.config/tools/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](https://ci.eclipse.org/packaging/job/epp/job/master/) that includes the above changes.
@@ -106,18 +115,17 @@ Scroll down for the per-milestone/RC steps.
 - [ ] Check that there are no warnings in the console output. Especially look for warnings about failure to sign.
   - If warnings about signings occur that leave the dmg unsigned and the build does not fail,
     please reopen [Bug 567916](https://bugs.eclipse.org/bugs/show_bug.cgi?id=567916).
-- [ ] Run the [Notarize MacOSX Downloads](https://ci.eclipse.org/packaging/job/notarize-downloads/) CI job to notarize DMG packages on download.eclipse.org.
+- [ ] Run the [Notarize MacOSX Downloads](
+      https://ci.eclipse.org/packaging/job/notarize-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](https://bugs.eclipse.org/bugs/show_bug.cgi?id=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](https://ci.eclipse.org/packaging/job/notarize-prepare-to-redo/)
-      to rename the -signed file back to `-tonotarize`
-      and then re-run the 
-      [notarize job](https://ci.eclipse.org/packaging/job/notarize-downloads/)
-      job.
+      Run [notarize-prepare-to-redo](
+      https://ci.eclipse.org/packaging/job/notarize-prepare-to-redo/
+      ) to rename the -signed file back to `-tonotarize` and then re-run the [notarize job](https://ci.eclipse.org/packaging/job/notarize-downloads/) job.
 - Other notes about notarization
   - **NOTE**
     It seems perfectly normal that the notarize job needs to be run multiple times as so many notarization attempts fail due to 500 and 000 response codes from the notarization server.
@@ -148,21 +156,20 @@ Scroll down for the per-milestone/RC steps.
 - [ ] Edit the [Jenkins build](https://ci.eclipse.org/packaging/job/epp/job/master/).
   - [ ] Mark build as Keep forever.
   - [ ] Edit Jenkins Build Information and name it, e.g., `2025-09 M3`.
-- [ ] Run the 
-      [Promote a Build](https://ci.eclipse.org/packaging/job/promote-a-build/)
-      CI job to prepare build artifacts and copy them to download.eclipse.org
+- [ ] Run the [Promote a Build](
+      https://ci.eclipse.org/packaging/job/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 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](https://www.eclipse.org/lists/epp-dev/msg06317.html).
     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](https://ci.eclipse.org/packaging/job/notarize-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](https://git.eclipse.org/r/c/epp/org.eclipse.epp.packages/+/189618)).
+- [ ] Run the [Notarize MacOSX Downloads](
+      https://ci.eclipse.org/packaging/job/notarize-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](https://git.eclipse.org/r/c/epp/org.eclipse.epp.packages/+/189618)).
 - [ ] Re-enable the [CI build](https://ci.eclipse.org/packaging/job/epp/job/master/).
 - [ ] Send email to epp-dev to request package maintainers test it.
       The email is templated in email.txt in the release directory.
@@ -187,15 +194,16 @@ Everything except R is typically the Friday around 9:30am Ottawa time and the R
 - [ ] **24 Hours before Final release** Make sure files are in final location to allow downloads to mirror.
   - [ ] Tag the release, e.g., with 2025-09_R.
         Example command line: `git tag --annotate 2025-09_R -m"2025-09 Release" 1b7a1c1af156e3ac57768b87be258cd22b49456b`.
-  - [ ] Run the 
-        [Rename Provisional to Final](https://ci.eclipse.org/packaging/job/rename-provisional-to-final/)
-        CI job to rename the provisional release milestone to final directory.
-        E.g.,
-        [2020-09/202009101200](https://download.eclipse.org/technology/epp/downloads/release/2020-09/202009101200/)
-         -> 
-        [2020-09/R](https://download.eclipse.org/technology/epp/downloads/release/2020-09/R/)
-        to match what is in [release.xml](https://download.eclipse.org/technology/epp/downloads/release/release.xml)) - 
-        this only applies to downloads, not to packages
+  - [ ] Run the [Rename Provisional to Final](
+        https://ci.eclipse.org/packaging/job/rename-provisional-to-final/
+        ) CI job to rename the provisional release milestone to final directory.
+        E.g., [2020-09/202009101200](
+        https://download.eclipse.org/technology/epp/downloads/release/2020-09/202009101200/
+        ) -> [2020-09/R](
+        https://download.eclipse.org/technology/epp/downloads/release/2020-09/R/
+        ) to match what is in [release.xml](
+        https://download.eclipse.org/technology/epp/downloads/release/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`.
@@ -204,13 +212,13 @@ Everything except R is typically the Friday around 9:30am Ottawa time and the R
 
 These jobs should be completed by approximately 10am Ottawa time on release days.
 
-- [ ] Run the 
-      [Finalize Release](https://ci.eclipse.org/packaging/job/finalize-release/)
-      CI job to create the "next" release and updated the "latest" release  as follows:
+- [ ] Run the [Finalize Release](
+      https://ci.eclipse.org/packaging/job/finalize-release/
+      ) CI job to create the "next" release and updated 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 specific https://download.eclipse.org/technology/epp/packages/yyyy-MM/ .
-  - The _next_ release sub-directory needs to be created immediately,
-    i.e., when 2019-12 was released, a directory 2020-03 had been created with an empty p2 composite repository pointing to 2019-12 until M1.
-    On M1 release day this changes to a composite p2 repository with M1 content.
+    This should be a composite pointing to specific https://download.eclipse.org/technology/epp/packages/yyyy-MM/.
+  - The _next_ release sub-directory needs to be created immediately.
+    - When 2019-12 was released, a directory 2020-03 had been created with an empty p2 composite repository pointing to 2019-12 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.
+       - Run the build once in `DRY_RUN` mode to ensure that the output is correct before it applies changes to download.eclipse.org.