The EPP Release Process

An online editable version of this document is on, 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 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.
  • [ ] Update splash screen (once per release cycle, hopefully done before M1). See detailed instructions.
  • [ ] Review packageMetaData packageName= and product name= entries in to ensure consistency with regards to use of incubation, speficially packages containing incubating components must have:
    • [ ] -incubation at the end of the product name (e.g. <product name="eclipse-cpp-2020-03-RC1-incubation" />)
    • [ ] (includes Incubating components) at the end of the packageMetaData packageName matching whitespace and letter case (e.g. packageName="Eclipse IDE for C/C++ Developers (includes Incubating components)")
  • [ ] Update name of the release in strings with a “smart” global find&replace. See this gerrit for an example. In particular, check:
    • [ ] packages/*/ for product name= line
    • [ ] Variables in parent pom releng/org.eclipse.epp.config/parent/pom.xml
    • [ ] On M1, whole version string is updated, including platform version (e.g. 4.14 -> 4.16); this is a large change including pom.xml, feature.xml, MANIFEST.MF,, and epp.product
  • [ ] When the year changes, e.g. between 2019-12 and 2020-03 releases, an update of the copyright year is required with a very smart search&replace.
  • [ ] Update the build qualifiers to ensure that packages are all updated. Run setGitDate script. This script will make a local commit.
  • [ ] 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
  • [ ] 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
  • [ ] Mark build as Keep forever
  • [ ] Edit Build Information and name it (e.g. 2020-03 M3)
  • [ ] Send email to epp-dev to request package maintainers test it.
  • [ ] For a release build, the additional parameters (see parent pom) should be set in the Jenkins build job to a meaningful time/date:
  • [ ] Run the Promote a Build CI job to prepare build artifacts and copy them to

    • [ ] Run the build once in DRY_RUN mode to ensure that the output is correct before it is copied to

    rsync --group --verbose ${REPO_ROOT}/compositeArtifacts${CHECKPOINT}.jar ${REPO_ROOT}/compositeArtifacts.jar
    rsync --group --verbose ${REPO_ROOT}/compositeContent${CHECKPOINT}.jar ${REPO_ROOT}/compositeContent.jar
  • [ ] 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. On M1 release day this changes to a composite p2 repository with M1 content. On other release days, add the new releases as children.

  • [ ] On release day, update release.xml which basically lists the relative locations of past, present, and future package releases. This will allow the webmasters to publish the new packages on the main Eclipse download page.