RELEASE.md

Releng-Tasks 2.0

Eclipse Major Release Schedule

Previous Documentation

Milestone and RC Releases

Friday before release week:

• Update I-builds to build on the milestone schedule (Twice daily at 06:00 EST and 18:00 EST except Thursday).
• Create or update prerequisite issues for tracking ECF, EMF and Orbit
• Send reminder email for upcoming milestone week to [email protected], [email protected], [email protected] and [email protected]
  • Example from 4.23 M1 but the usual schedule:
    • Monday: Last day of development.
    • Tuesday: Tests
    • Wednesday:
      • Fixes from Tuesday.
      • "New and Noteworthy entries due.
      • Release Candidate is built Wednesday evening at 6PM EST.
    • Thursday: Sign-Off
    • Friday:
      • Build delcared and released.
      • Make sure to mention that the Master branch will stay closed until the milestone is officially released.

Milestone Week

• Wednesday:
  • Verify that EMF, ECF and Orbit contributions have been included (if applicable).
  • Final release candidate build runs at 6PM EST.
  • Because of time zones, PST/EST might want to do Thursday's tasks EOD Wednesday after the release candidate has built.
• Thursday:
  • Create a Sign-Off issue for the Release Candidate in eclipse.platform.releng.aggregator.
    • Example issue #198
    • If RC build is successful there should be an email sent to platform-releng-dev with the download and repository links needed for the issue.
    • Deadlines are Friday at whatever time you intend to promote the RC.
  • Send email asking for component go/no go to [email protected], [email protected], [email protected] and [email protected]
    • Just 1 line asking for sign off on the GitHub issue created in the previous step.
• Friday:
  • Promote the release candidate (if go).
    • Run the rename and promote job in Jenkins
      • DROP_ID: Release candidate build ID (make sure there is no space before or after the ID).
      • CHECKPOINT: M1 etc (blank for final releases)
      • SIGNOFF_BUG: Needs to be updated to sign-off issue (numeric part only)
      • TRAIN_NAME: Whenever the current GA release is planned for (formatted 4 digit year - 2 digit month, i.e 2022-06)
      • STREAM: 4.24.0 etc
      • DL_TYPE: S is used to promote I-builds.
      • After the build find and open the mail template artifact and have it ready.
    • Contribute to SimRel
      • If you have not already set up SimRel you can do so using Auto Launch here
      • Clone org.eclipse.simrel.build (Should have been done by the installer during set up, but make sure you have latest).
        1. Open simrel.aggr in Eclipse
        2. Change to the properties view
        3. Select Contribution:Eclipse > Mapped Repository
        4. Update the Location property to the "Specific repository for building against" in the mailtemplate.txt from promotion.
        5. Commit Simrel updates to Gerrit
           • Message should use year-month format, i.e "Simrel updates for Eclipse and Equinox for 2022-06 M1"
    • Make the build visible
      • Run the make visible job in Releng jenkins to make the promoted build visible on the download page.
      • Parameters should match Rename and Promote job
      • This should automatically run tag Eclipse release to tag the source code.
      • Tag Parameter should match stream version, i.e S4_24_0_M1 etc
    • Send email that the M1 build is available
      • Use the mail template from the promotion build artifacts in Jenkins to get the download urls.
    • For Milestone builds return the I-builds to the normal schedule.
  • Update ECJ compiler in the platform build (if it needs to be updated).
    • To find the new compiler version:
      • Go to the update site for the release candidate
      • Click plugins
      • Find org.eclipse.jdt.core.complier.batch_${ecjversion}.jar
    • Edit the copyAndDeployJDTCompiler job in Jenkins
      • Only JDT committers can run the job, but Releng/Platform committers can configure it
      • Update the default values of the versionfolder, buildid and ecjversion parameters.
      • Update the build triggers to schedule a build for the current date.
    • Finally update the cbi-ecj-version in eclipse.platform.releng.aggregator/eclipse-platform-parent/pom.xml
  • After RC1
    • Open an issue in eclipse.platform.releng.aggregator to enable the API Freeze Report for the current release.
      • Open buildproperties.txt
      • Comment out the empty FREEZE_PARAMS line and uncomment the line with the freeze arguments. Update freezeBaseURL with the RC1 build number.
      • Comment out the empty API_FREEZE_REF_LABEL line and update the version of the label to RC1.
    • Leave the I-builds running on the milestone schedule for RC2.
    • Comment on EMF, ECF and Orbit issues to ask for final release builds.

GA Releases

After RC2

• Create an issue to track the current release tasks (see Release 4.24).
  • Tag @lshanmug (New & Noteworthy), @SarikaSinha (Readme), @vik-chand (Tips & Tricks), @ktatavarthi (JDT and Platform Migration Guides), @niraj-modi (SWT Javadoc bash).
  • Update the Acknowledgements.
• Create an issue to track preparation work for the next stream (see Preparation work for 4.25 (2022-09)).
• Maintenance Branch Creation:
  • Create the branch from RC2 using the create maintenance branch job in the Eclipse Platform Releng jeknins.
• Update Jenkins for the next Release:
  • Edit the JobDSL.json
    • Add the next release version to the Streams key item.
    • In the branches item update the current release to map to the maintenance branch and add a new key:value pair mapping the next release to master.
  • Update deployPlatformParentPom.groovy and deploySdkPom.groovy to include the new maintenance branch.
  • Run the Create Jobs job in Jenkins. This should move the current I-builds to run on the maintenance branch and create new I-builds for the next release. Performance and Unit tests should also be generated for the new release automatically.
• Create new Stream Repo:
  • Run the Create New Stream Repos job to make an I-builds repo for the next release.
• Update the Build Calendar:
  • Create an issue and update the build calendar for the next GA release based on the Simultaneous Release schedule.
    Each stream has its own wiki page with a more detailed schedule.
• Update Splash Screen:
  • Update splash screen.
    Splash screens are created 4 at a time, for 4 consequtive quarterly releases, so they only need to be requested once a year before the 20XX-06 release (the cycle is 2022-06 -> 2023-03, etc). Create an issue in the Eclipse Help Desk similar to Bug 575781. It is customary to do this by the previous -09 (September) release so that there's plenty of time for discussion before the -06 (June) release is opened.
• General Cleanup
  • Update cleanup scripts to include Y and P-builds if those were added, or take them out if not.
  • Cleanup approved API list.
  • Clean forceQualifierUpdate files for doc bundles. The context here is that the doc builds only check for changes in this repo and so these files need to be changed to trigger a full rebuild.
• Version Updates
  These updates are currently broken into multiple github issues, but the changes can be made at once and merged in a single commit.
  • Set the previous version to RC2.
  • Update versions to the next release across product files and build scripts:
    POM and product version changes
    Update product version number across build scripts.
    This is a large task so it's better to get started as soon as possible after the RC2 release, though it won't be merged until there's a final GA candidate. Most of the version updates can be done by updating updateProductVersion.sh and running it in eclipse.platform.releng.aggregator. Clone recursively to get each submodule:

    git clone -b master --recursive git clone -b master --recursive [email protected]:eclipse-platform/eclipse.platform.releng.aggregator.git
    

    then run updateProductVersion.sh, then commit the changes in a new branch for each repo. Once that's done it's easiest to just grep for the previous release version or stream number to find the remaining instances that need to be updated.
    The repos that need to be updated (excluding the ones included in eclipse.platform.releng.aggregator) are:
    • eclipse-platform/eclipse.platform.releng.aggregator
    • eclipse-platform/eclipse.platform.runtime
    • eclipse-equinox/p2
    • eclipse-equinox/equinox.framework
    • eclipse-equinox/equinox.bundles
  • Disable the freeze report for the next stream.
  • Update the checkComposities script.
  • Update comparator repo and eclipse run repo.
  • Update version number in mac's Eclipse.app.

RC2a Release

• Sometimes there is a critical issue that requires a fix, if it's decided that one is needed then an RC2a (followed by RC2b, RC2c etc if necessary) is built from the maintenance branch and promoted using the RC2 process.
• Create an issue to set the previous release version to RC2a and add it to the Preparation issue for the next version, then update all references to RC2 to the RC2a release.

Friday before GA Release

• After Simrel declares RC2 run the rename and promote job to promote RC2 (or RC2a). Change the DL_TYPE from S to R.
  You can subscribe to cross-project-issues to get the notifications on Simrel releases.
• Once you have the release url for the GA release...
• Publish Maven artifacts to oss.sonatype.org staging area to prepare for Maven Central and send a mail to the mailing-list sharing the URLs of the Maven staging repositories for testing.
• Update maintenance branch with release version tasks.
• Set the previous release to the GA release across build scripts.
• Update and contribute to Simrel.

Publishing to Maven

• Publishing to maven should happen by at least Tuesday before the release since there is up to a 24 hour delay for the maven mirrors.
• Update SDK4Mvn.aggr and properties.sh to the release build, and update EMF and Orbit urls.
• Run the CBI aggregator job in jenkins.
  • Sometimes there are new source bundles that need to be added/generated, add these to sourceBundles.txt
• Run Publish Platform to Maven, Publish JDT to Maven and Publish PDE to Maven in parallel, using the CBI aggregator build number for the argument.
• If you do not have an account on oss.sonatype.org for performing the rest of the release request one by creating an issue like https://issues.sonatype.org/browse/OSSRH-43870 to get permissions for platform, JDT and PDE projects and tag an existing release engineer to give approval.
• Log into https://oss.sonatype.org/#stagingRepositories and close the Platform, JDT and PDE repositories.
• Replace contents of baseline.txt with the contents of baseline-next.txt created in CBI aggregator.

Wednesday, GA Release

• The release is scheduled for 10AM EST
• The Tag Eclipse Release needs to be run before then, so it's usually scheduled to run at about 8AM EST. This will complete the Tag GA release task.
• For the Clean up intermediate artifacts task, update the cleanup release artifacts job and schedule it to run at 8AM on Wednesday. Use the list artifacts job to generate the list used by the cleanup job.
• At around 9:30 EST run (or have scheduled) ep_createGenericComposites to update the generic repos for this release.
  For reference, the generic repositories are for the latest GA release and the current (ongoing) I-builds, Y-builds and P-builds.
• Schedule the make visible job for about 9:45AM EST.
• Complete publication Maven Central: go to https://oss.sonatype.org/#stagingRepositories and "Release" the already closed staging Maven repositories.
• Once Simrel announces the GA release send the announcement email.