The EPP Release Process

An online editable version of this document is on hackmd.io, updates should be copied to Eclipse's git repo. The Eclipse version is the official one.

This guide contains the step-by-step process to complete an EPP release.

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

Steps for M1:

Steps for all Milestones and RCs:

  • [ ] Ensure that the CI build is green. Resolving non-green builds will require tracking down problems and incompatibilities across all Eclipse participating projects. cross-project-issues-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 build output for report of check-incubating.sh script.
    • -incubation and (includes Incubating components) are not used in packageMetaData anymore (See Bug 564214)
  • [ ] Update the “new and noteworthy” version numbers: (Normally only done on M3 and RCs, requires https://projects.eclipse.org/releases/ to have been updated/created for the release)
    • [ ] Search for url= (notice the blank before url) in epp.website.xml to see which ones are contained in the different packages.
    • [ ] Use global search and replace to update the version numbers at the end of the URLs.
    • [ ] 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 lookup the feature version to be released with the release train.
  • [ ] Update the JustJ version - look for announcements, particularly from Ed to epp-dev
  • [ ] 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 gerrit for an example. Use commit message like Update strings for 2020-09 M2. In particular, check:
    • [ ] packages/*/epp.website.xml for product name= line
    • [ ] Variables in parent pom releng/org.eclipse.epp.config/parent/pom.xml
    • [ ] release.xml template in releng/org.eclipse.epp.config/tools/promote-a-build.sh
  • [ ] Update the build qualifiers to ensure that packages are all updated. See this gerrit for an example. To do this run releng/org.eclipse.epp.config/tools/setGitDate script. This script will make a local commit you need to push.
  • [ ] Wait for announcement that the staging repo is ready on cross-project-issues-dev. An example announcement.
  • [ ] Run a CI build that includes the above changes.
  • [ ] Check that there are no unexpected warnings in the console output. Especially look for warnings about failure to sign. (Warnings about Mirror tool seem to be ok and can be ignored. In a historically good build there is one [WARNING] Mirror tool: Messages while mirroring artifact descriptors. per package)
  • [ ] Sanity check the build for the following:
    • [ ] Download a package from the build's artifacts artifact/org.eclipse.epp.packages/archive/
    • [ ] Made sure filenames contain expected build name and milestone, e.g. 2020-03-M2
    • [ ] Splash screen says expected release name (with no milestone), e.g. 2020-03
    • [ ] Help -> About says expected build name and milestone, e.g. 2020-03-M2
    • [ ] 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 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 (Such as JDT, Platform) have been upgraded.
  • [ ] Edit the Jenkins build
    • [ ] Mark build as Keep forever
    • [ ] Edit Jenkins Build Information and name it (e.g. 2020-03 M3)
  • [ ] For a release build, the additional parameters (see parent pom) should be set in the Jenkins build job to a meaningful time/date TODO: Move this into the build itself and/or updated by the string updates/setGitDate in the above steps:
eclipse.simultaneous.release.build=20191212-1212
  • [ ] Run the Promote a Build CI job to prepare build artifacts and copy them to download.eclipse.org
    • [ ] Run the build once in DRY_RUN mode to ensure that the output is correct before it is copied to download.eclipse.org.
  • [ ] Run the Notarize MacOSX Downloads CI job to notarize DMG packages on download.eclipse.org
  • [ ] Run Touch All Files See Bug 568574: Touch all files for the milestone in the download area to make sure mirrors are not misreporting them as mirrored before sending announcements.
  • [ ] Update the LastRecorded+1.txt which any package and platform +1s that have been received since the last update.
  • [ ] Send email to epp-dev to request package maintainers test it, including the last recorded +1 details.
  • [ ] 24 Hours before Final release Make sure files are in final location to allow downloads to mirror
  • [ ] On release days approximately 9:30am check that the below worked:
  • [ ] On Final release day immediately after a release (just after 10am):
    • [ ] The next release sub-directory needs to be created immediately after a release, 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. (Use Job https://ci.eclipse.org/packaging/view/Packages/job/epp-createNextRelease/) On M1 release day this changes to a composite p2 repository with M1 content. On other release days, add the new releases as children and on final release this changes to a composite with just the one child.