Eclipse Major Release Schedule
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 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.
- Example from 4.23 M1 but the usual schedule:
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.
- Create a Sign-Off issue for the Release Candidate in eclipse.platform.releng.aggregator.
- 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).
- Open simrel.aggr in Eclipse
- Change to the properties view
- Select Contribution:Eclipse > Mapped Repository
- Update the Location property to the "Specific repository for building against" in the mailtemplate.txt from promotion.
- 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 this job in Releng jenkins
- Parameters should match Rename and Promote job
- Run Tag Eclipse Release to tag the source code.
- Tag Parameter should match stream version, i.e
S4_24_0_M1
etc
- Tag Parameter should match stream version, i.e
- 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.
- Run the rename and promote job in Jenkins
- Update ECJ compiler in the platform build.
- 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
andecjversion
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
- To find the new compiler version:
- 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. UpdatefreezeBaseURL
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.
- Open an issue in eclipse.platform.releng.aggregator to enable the API Freeze Report for the current release.
- Promote the release candidate (if go).
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 an issue for maintenance branch creation from the item in the Preparation issue created above.
Create the branch from RC2 using the ep-createMaintenanceBranch job in the Eclipse Platform Releng jeknins. - Create an issue for moving I-builds to the maintenance branch.
- Create an issue to Update parent pom and target sdk deployment jobs in jenkins.
Update deploy-eclipse-sdk-target-pom and deploy-eclipse-platform-parent-pom jobs to include the new maintenance branch.
- Create an issue for maintenance branch creation from the item in the Preparation issue created above.
- 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. - Create an issue to track the creation of new Performance Test and Automated Test jobs in the Releng jenkins.
- Create an issue and run the newStreamRepos job to make an I-builds repo for the next release. Once the repos are made create new I-build (and Y or P-builds as necessary) for the next release.
- 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.
- 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.
- 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 ineclipse.platform.releng.aggregator
. Clone recursively to get each submodule:then rungit clone -b master --recursive git clone -b master --recursive [email protected]:eclipse-platform/eclipse.platform.releng.aggregator.git
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 ineclipse.platform.releng.aggregator
) are: - 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 you can complete the Publish to Maven Central and 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, then select each and click release to release them.
- 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.
- Once Simrel announces the GA release send the announcement email.