Skip to content

Latest commit

 

History

History
233 lines (208 loc) · 23 KB

RELEASE.md

File metadata and controls

233 lines (208 loc) · 23 KB
Raw

Releng-Tasks 2.0

Eclipse Major Release Schedule

Milestone and RC Releases

Friday before release week:

Milestone/RC Week

  • M 1/2/3 Release
    • All milestone releases are 'lightweight', meaning there is no announcement or signoff. No additional builds need to be run, just the daily I-build at 6PM EST. Thursdays build is promoted to simrel on friday (unless there are problems with Thursdays build, in which case promote Wednesdays) and the compiler is updated if necessary, but the promote and makevisible jobs don't need to be run.
  • 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:
  • 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.
        • TAG: Parameter should match stream version, i.e S4_30_0_RC1 etc
        • After the build find and open the mail template artifact and have it ready.
        • This should automatically run tag Eclipse release to tag the source code.
      • 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
      • Send email that the M1 build is available
        • Use the mail template from the promotion build artifacts in Jenkins to get the download urls.
        • Make sure to mention that the Master branch is now again open for development.
      • 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
      • Leave the I-builds running on the milestone schedule for RC2.
      • Comment on EMF, ECF and Orbit issues to ask for final release builds.
    • After RC2

GA Releases

Tasks to be completed after RC2

Release Preparation:

Tasks that need to be completed before Friday

Release:

The actual steps to release

Friday

  • Promote to GA

    • After Simrel declares RC2 (usually the Friday before release) run the rename and promote job to promote RC2 (or RC2a). If the daily cleanup for old builds job was not disabled and the original I-build is no longer available you can use the promoted RC2 build.
      • Change the DL_TYPE from S to R.
      • TAG will be set to R as well, for example R4_27
    • You can subscribe to cross-project-issues to get the notifications on Simrel releases.

  • Publish to Maven central

  • Contribute to SimRel
    • If SimRel is not updated before the I-builds are cleaned up (specifically the build for RC2/GA) it will break.

Wednesday
The release is scheduled for 10AM EST. Typically the jobs are scheduled beforehand and run automatically.

  • Create Generic Composites

  • Run the Create Generic Composites job to recreate the generic build repos for the next release.
    • currentStream: To clarify this is the next stream, not the one currently being released. If you are releasing 4.24, the 'current' stream is 4.25 so that repos are created for it.
    • previousStream: The stream being released, which needs to be removed.
    • For reference, the generic repositories created are for the latest GA release and the current (ongoing) I-builds, Y-builds and P-builds.
  • Make the Release Visible
    • Same process as for a milestone but with release versions.
  • Complete Publication to Maven Central
  • Send the Announcement Email

Post Release Tasks:

  • Clean up intermediate artifacts

    • To clean up specific artifacts from the old stream (milestones, I-builds and old releases) run the Cleanup Release Artifacts job.
    • release_to_clean is the release that was just published.
    • release_build is the I-build that was promoted, this is used as a landmark to the build will clear out all previous I-builds.
    • release_to_remove only the last 3 major releases are kept on the download page, so if 4.25 was promoted then remove 4.22.
    • For the Y and P build parameters it's important to know whether or not Y and P builds were run during the release. Since they correspond to java releases on a 6 month cycle, typically they are built in odd-numbered releases.
      The existing builds are kept for one release, then cleaned up before the next stream that will have Y and P builds. it's convoluted and I dont want to type it out. Remove Y builds on even releases.
    • If something doesn't get cleaned up properly you can use Use the list artifacts job to generate ta list of what's on the download server and either create a new job to clean it up or update and rerun the cleanup job as appropriate.
  • Set Maven to Publish to I-builds
    • Update SDK4Mvn.aggr and point it to the new streams I-builds.
  • Set Previous Release to GA
    • Everything that was updated to RC2 (see below) should now use the released build.

Preparation for the next Release

After RC2 create an issue to track preparation work for the next stream (see Preparation work for 4.25 (2022-09)).

  • A script to create this issue exists here for those who have the hub cli tool installed. The process has been in flux recently so please update the script if necessary, but it provides a helpful template since most tasks in the previous release's issue become links.

Maintenance Branches:

  • Maintenance Branch Creation:
  • Update maintenance branch with release version
    • Once the I-build repo is removed for the previous release the maintenance branch will have to use the release location, i.e. any references to https://download.eclipse.org/eclipse/updates/4.25-I-builds/ will need to be updated to https://download.eclipse.org/eclipse/updates/4.26/R-4.26-202211231800/
    • Functionally this means:
    • This step can be prepared ahead of time but can't be merged until the release build has been promoted and the update site exists.

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.
  • List of people who can edit the calendar
    • Alexander Kurtakov(@akurtakov)
    • David Williams
    • Gireesh Punathil
    • Rahul Mohanan
    • Samantha Dawley
    • Sravan Kumar Lakkimsetti

Update Splash Screen:

  • Create a tracking issue in eclipse.platform and link it to the main issue in eclipse.platform.releng.aggregator.
  • Future spash screens are kept in a subfolder of eclipse.platform/platform/org.eclipse.platform, usually named something like 'splashscreens2022' (or the current year).
  • Find the appropriate splash screen, copy it one level up and rename it splash.png, replacing the existing png.
  • NOTE: Splash screens are created 4 at a time, for 4 consequtive quarterly releases, so they 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.
  • Issue for the 2023 releases is https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/2336

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:

Create Git Milestones for the next Release:

  • Milestones in git are created by running the create-milestones job in jenkins, usually after RC1 or RC2. Only specific users can access this job for security reasons. If milestones need to be created and have not please contact @sdawley @sravanlakkimsetti or @laeubi to run it.

Version Updates:

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.