Skip to content

Latest commit

 

History

History
162 lines (139 loc) · 14.6 KB

RELEASE.md

File metadata and controls

162 lines (139 loc) · 14.6 KB

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 Build and Publish Promoted Build 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 Promote Build job in Jenkins
        • DROP_ID: ID of the build to promote, e.g.: I20250817-1800
        • CHECKPOINT: M1 etc. (blank for final releases)
        • SIGNOFF_BUG: Needs to be updated to sign-off issue (numeric part only)
        • For Milestones/RC promotions, this should automatically run the Publish Promoted Build job to make the promoted build immediatly visible on the download page.
      • Contribute to SimRel
        • If you have not already set up SimRel you can do so using Auto Launch here
        • Clone 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 GitHub
            • Message should use year-month format, i.e "Simrel updates for Eclipse and Equinox for 2022-06 M1"
    • After RC1
      • Comment on EMF, ECF and Orbit issues to ask for final release builds.

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 Promote Build job to promote RC2 (or RC2a).
      • DROP_ID: Final delease candidate's ID, e.g.: S-4.36RC2-202505281830/
      • This will create pull requests to update the build configuration on the master and corresponding maintenance branch to the promoted release.
        • Only submit them AFTER the release was finally published.
    • You can subscribe to cross-project-issues to get the notifications on Simrel releases.
  • 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.

  • Make the Release Visible
    • Run the Publish Promoted Build job in Releng jenkins to make the promoted build visible on the download page.
      • releaseBuildID: the full id of the release build to publish, e.g. R-4.36-202505281830
  • Complete Publication to Maven Central
    • The final release to Maven-Central should happen latest by Tuesday before the release since there is up to a 24 hour delay for the Maven mirrors.
    • The artifacts have been deployed into a Maven-Central staging repository by the Promote Build job when the RC was promoted to GA release.
    • Login to https://central.sonatype.com/ and "Release" the three staging repositories for Platform, JDT and PDE by closing them.
      • Make sure the name of the deployment you are about to release matches the tag and timestamp of the final release repository. E.g for a P2 repo with id R-4.36-202505281830 the deploymenets should be named PLATFORM_R-4.36-202505281830, PDE_R-4.36-202505281830 or JDT_R-4.36-202505281830 respectivly.
      • If you do not have an account on central.sonatype.com for performing the rest of the release request one by creating an EF Help Desk issue to get permissions for platform, JDT and PDE projects and tag an existing release engineer to give approval.

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.

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:

  • Run the Create Jobs job in Jenkins. But until the preparation work has completed, the new I-builds should not be triggered in order to avoid undesired interference. To ensure this, either
    • Run the Create Jobs job only after all preparation work is reviewed and submitted and the first I-build can run.
    • Disable the new I-build job until it's ready to run it the first time. In order to investigate the state of the I-build it's probably also good to disable the job again after the first I-build has completed, until the master is open for regular development.
  • Move the previous (still existing) I-Build job to run on the maintenance branch (and remove it's cron trigger). That job can be deleted (together with its test jobs), when we are sure RC respins won't happen anymore.

Create Git Milestones for the next Release:

Milestones are already created by running Prepare Next Development Cycle job. Previously they were created in ther own job:

  • 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:

  • Running the Prepare Next Development Cycle job will update pom and product versions for the Eclipse repositories and submit pull requests for the changes.
    This is still a work in progress so if there are any issues or a repo gets missed you can fall back to the old process below:
    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, then commit the changes in a new branch for each repo.
  • Update comparator repo and eclipse run repo
    • Update the ECLIPSE_RUN_REPO in the cje-production buildproperties.txt files
  • Set Previous Version to RC2

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.