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 at the beginning of each release cycle (i.e. before M1):** - [x] Fix and - [x] Create new [PMI entry]( - [x] Add Target Milestones and Versions in [Bugzilla]( - [x] Update splash screen (once per release cycle, hopefully done before M1). See detailed [instructions]( For 2021-06 see Bug [569333]( for new splash screens. - [x] 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. A good replacement is `/, 2021/, 2022/` excluding `*.svg` - [x] 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 pom.xml, feature.xml, MANIFEST.MF,, epp.product, build.xml, and p2.inf - [x] `2020-12` -> `2021->03` part - [x] `4.14` -> `4.15` part - [ ] rsync the downloads area to and remove non-R downloads. - [ ] Remove the old M and RC builds with - [ ] rsync the last release to the archives with - [ ] Remove releases from by listing releases to delete and then running (TODO create this job) **Steps for all Milestones and RCs:** - [ ] Ensure that the [CI build]( is green<!-- or yellow (yellow means some files have failed to notarize which can be handled later on in this process)-->. 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 script. - `-incubation` and ` (includes Incubating components)` are not used in packageMetaData anymore (See [Bug 564214]( - [ ] 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 `` 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 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 the full names of the JRE bundles in [remove-justj-from-p2.xml]( - [x] 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 `[releng] Prepare repo for 2020-12 M1`. In particular, check: - On M1 add the M1 qualifier (e.g. `2021-03-R` -> `2021-06-M1`, on RC2 set it to `R` the qualifier e.g. `2021-03-RC1` -> `2021-03-R`). **Except** for `` which should go from `2021-03 (4.19.0)` -> `2021-06 M1 (4.20.0 M1)` on M1 and `2021-03 RC1 (4.19.0 RC1)` -> `2021-03 (4.19.0)` on RC2 - [x] `packages/*/` for `product name=` line - [x] Variables in parent pom `releng/org.eclipse.epp.config/parent/pom.xml` - On R build, for `` remove qualifier i.e. it should be `2020-12 (4.18.0)` - On M1 build add the qualifier back in, for `` remove qualifier i.e. it should be `2020-12 M1 (4.18.0 M1)` - [x] release.xml template in `releng/org.eclipse.epp.config/tools/` - [x] `RELEASE_NAME` and `RELEASE_MILESTONE` in `releng/org.eclipse.epp.config/tools/` - [ ] 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. - [ ] Disable the [CI build]( so that the build results are not overwritten while doing the promotion - [ ] Run the [Notarize MacOSX Downloads]( CI job to notarize DMG packages on<!-- if the promoted build was unstable-->. *This can be done after promotion if time is tight or the notarization fails repeatedly. See [Bug 571669]( for an example of failures.* - [ ] 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) - If warnings about signings occur that leave the dmg unsigned and the build does not fail, please reopen [Bug 567916]( - [ ] Sanity check the build for the following: - [ ] Download a package from the build's [staging output]( - [ ] 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. - `` - `` - [ ] Verify 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. `2020-03 M3`) - [ ] Run the [Promote a Build]( CI job to prepare build artifacts and copy them to - [ ] *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 - [ ] Run the [Notarize MacOSX Downloads]( CI job to notarize DMG packages on if the promoted build was unstable - [ ] **TODO add this to the promote a build script** 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. - [ ] Re-enable the [CI build]( - [ ] 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. Include the last recorded +1 details during M3-RC2 emails. - [ ] **24 Hours before Final release** Make sure files are in final location to allow downloads to mirror - [ ] 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 This can be done with a script like **TODO: make a job for this** : ``` ssh /bin/bash << EOF set -u # run with unset flag error so that missing parameters cause build failure set -e # error out on any failed commands set -x # echo all commands used for debugging purposes mv -v /home/data/httpd/ /home/data/httpd/ touch /home/data/httpd/* EOF ``` - [ ] **On release days** approximately 9:30am - [ ] check that this worked: copy the composite\*RC1.jar files over the composite\*.jar files in - this is done automatically with the [EPP Make Visible job]( which is automatically triggered by simrel's [SimRel Make Visible Job]( - [ ] Tag the release, e.g. with 2020-03_R. Example command line: `git tag -s -a 2020-03_R -m"2020-03 Release" 1b7a1c1af156e3ac57768b87be258cd22b49456b` - [ ] **On Final release day** immediately _after_ a release (just after 10am): - [ ] The current release needs to be promoted as "latest" under . This should be a composite pointing to specific . This is achieved by triggering the [epp-promoteReleaseToLatest]( - [ ] 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 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.