Skip to content

Adapt Release and RelEng documentation to reworked release automation #3679

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
HannesWell wants to merge 1 commit into
base: master
Choose a base branch
from
Draft

Adapt Release and RelEng documentation to reworked release automation #3679

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 15 additions & 1 deletion JenkinsJobs/Releng/prepareNextDevCycle.jenkinsfile
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -364,10 +364,24 @@ pipeline {
def prBranch = "prepare-R${NEXT_RELEASE_VERSION}"
def aggregatorPreparationPR = githubAPI.createPullRequest('eclipse-platform/eclipse.platform.releng.aggregator', prHeadline, """\
Prepare development of Eclipse ${NEXT_RELEASE_VERSION}.
This includes:
This includes(inter alia):
- Updating the version of the Maven parent, all references to it and the Eclipse products to `${NEXT_RELEASE_VERSION}`
- Updating the release version to `${NEXT_RELEASE_VERSION}` across build scripts
- Updating the previous release version to the current Release-Candidate: `${PREVIOUS_RELEASE_CANDIDATE_ID}`

Further tasks:
- [ ] Review and submit all PRs created in the submodules to prepare them for the new release cycle.
All of these PRs are linked to this one.
- [ ] Review and submit the creation of the N&N pages for the new stream in the [eclipse website](https://github.com/eclipse-platform/www.eclipse.org-eclipse/pulls) repository.
- [ ] Submit this PR.
Before the preparation PRs in all submodules have been submitted the build of this change cannot complete
(this can still submit it before).
- [ ] Update build calendar for platform ${NEXT_STREAM} release.

After this and all submodule PRs are submitted:
- [ ] Run the [`Create Jobs`](https://ci.eclipse.org/releng/job/CreateJobs/) seed job to generate the Jenkins jobs for the new stream
- [ ] Start the new [`I-build-${NEXT_RELEASE_VERSION}`](https://ci.eclipse.org/releng/job/Builds/job/I-build-${NEXT_RELEASE_VERSION}/) job for the first I-build of the new stream

""".stripIndent(), prBranch)

utilities.forEachGitSubmodule{ submodulePath ->
Expand Down
70 changes: 30 additions & 40 deletions RELEASE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
# Releng-Tasks 2.0
# Releng-Tasks 2.1

[Eclipse Major Release Schedule](https://github.com/eclipse-simrel/.github/blob/main/wiki/Simultaneous_Release.md)

Expand Down Expand Up @@ -39,6 +39,9 @@
- `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](https://ci.eclipse.org/releng/job/Releng/job/publishPromotedBuild/) job to make the promoted build immediatly visible on the download page.
<!-- TODO: submit created acknoledgements PR! -->
- This will automatically run the [Generate Acknowledgements](https://github.com/eclipse-platform/www.eclipse.org-eclipse/actions/workflows/generateAcknowledgements.yml) workflow.
Check if changes were made and thus a PR was created and review it (pay special attention about name conflicts mentioned in the PR message and make sure they are resolved). Then submit it.
* Contribute to SimRel
- If you have not already set up SimRel you can do so using Auto Launch [here](https://www.eclipse.org/setups/installer/?url=https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/interim/SimultaneousReleaseTrainConfiguration.setup&show=true)
- Clone [org.eclipse.simrel.build](https://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git) (Should have been done by the installer during set up, but make sure you have latest).
Expand All @@ -59,59 +62,60 @@ Tasks that need to be completed before Friday

* Create an issue to track the current release tasks (see [Release 4.24](https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/273)).
- Tag @SarikaSinha (Readme), @ktatavarthi (JDT and Platform Migration Guides), @niraj-modi (SWT Javadoc bash).
- Update the Acknowledgements.
- A script to create this issue exists [here](scripts/GAReleasePrep.sh) for those who have the hub cli tool installed.
* **Readme**
Currently handled by @SarikaSinha
- Create a tracking issue in [www.eclipse.org-eclipse](https://github.com/eclipse-platform/www.eclipse.org-eclipse) (see [Readme file for 4.26](https://github.com/eclipse-platform/www.eclipse.org-eclipse/issues/24) as an example).
- Add Readme files and update generatation scripts.
* **Acknowledgements**
- Create a tracking issue in [www.eclipse.org-eclipse](https://github.com/eclipse-platform/www.eclipse.org-eclipse) and link it to the main release issue in eclipse.platform.releng.aggregator.
- Create a new acknowledgements file for the current release and add it to [www.eclipse.org-eclipse/development](https://github.com/eclipse-platform/www.eclipse.org-eclipse/tree/master/development).
- The previous acknowledgement files are there for reference.
* **Migration Guide**
- Create a tracking issue in [eclipse.platform.common](https://github.com/eclipse-platform/eclipse.platform.common) and link it to the main release issue in eclipse.platform.releng.aggregator.
- Every release a new porting guide and folder need to be added to [eclipse.platform.common/bundles/org.eclipse.jdt.doc.isv/porting](https://github.com/eclipse-platform/eclipse.platform.common/tree/master/bundles/org.eclipse.jdt.doc.isv/porting), named with the version being migrated *to*.
- i.e `eclipse_4_27_porting_guide.html` is for migrating from 4.26 tp 4.27.
- Update topics_Porting.xml in [eclipse.platform.common/bundles/org.eclipse.jdt.doc.isv](https://github.com/eclipse-platform/eclipse.platform.common/tree/master/bundles/org.eclipse.jdt.doc.isv) and [eclipse.platform.common/bundles/org.eclipse.platform.doc.isv](https://github.com/eclipse-platform/eclipse.platform.common/tree/master/bundles/org.eclipse.platform.doc.isv)
- Update the name of the proting html document in [eclipse.platform/platform/org.eclipse.platform/intro/migrateExtensionContent.xml](https://github.com/eclipse-platform/eclipse.platform/blob/master/platform/org.eclipse.platform/intro/migrateExtensionContent.xml)
* **SWT Javadoc bash**
Currently handled by @niraj-modi
- Create a tracking issue in [eclipse.platform.swt](https://github.com/eclipse-platform/eclipse.platform.swt).
- The javadoc bash tool needs to be run on SWT sources to make it consistent.

### **Release**:
The actual steps to release

**Friday**
* #### **Promote to GA**
- After Simrel declares RC2 (usually the Friday before release) run the [Promote Build](https://ci.eclipse.org/releng/job/Releng/job/promoteBuild/) job to promote RC2 (or RC2a).
- After Simrel declares RC2 (usually the Friday before release) run the [Promote Build](https://ci.eclipse.org/releng/job/Releng/job/promoteBuild/) job to promote RC2 (or RC2a) to be the final release.
- `DROP_ID`: Final delease candidate's ID, e.g.: `S-4.36RC2-202505281830/`
- `CHECKPOINT`: blank for final releases
- This will automatically run the [Generate Acknowledgements](https://github.com/eclipse-platform/www.eclipse.org-eclipse/actions/workflows/generateAcknowledgements.yml) workflow.
Check if changes were made (unlikly for final release promotion) and thus a PR was created and review it (pay special attention about name conflicts mentioned in the PR message and make sure they are resolved). Then submit it.
- 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](https://accounts.eclipse.org/mailing-list/cross-project-issues-dev) 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](https://ci.eclipse.org/releng/job/Releng/job/publishPromotedBuild/) 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`
**Tuesday/Monday**
* **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](https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues) issue to get permissions for platform, JDT and PDE projects and tag an existing release engineer to give approval.
* **Contribute to SimRel**
- The final release repo has to be contributed to SimRel before the currently active I-build repo is deleted (hopefully automatically by the publication job)

**Wednesday**
The release is scheduled for 3PM UTC.
<!-- TODO: discuss to do this earlier? -->

* **Make the Release Visible**
- Run the [Publish Promoted Build](https://ci.eclipse.org/releng/job/Releng/job/publishPromotedBuild/) 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`

### **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)](https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/284)).
- A script to create this issue exists [here](scripts/newReleasePrep.sh) 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.
After RC2 is promoted/published run the [`Prepare Next Development Cycle`](https://ci.eclipse.org/releng/job/Releng/job/prepareNextDevCycle/) job
and check and submit the Pull-Requests created by it in the `eclipse.platform.releng.aggregator` repository and all its submodules.
<!-- TODO: describe the arguments and move this to RC2 post tasks?? -->

#### **Update the Build Calendar:**
<!--TODO: automate that too -->
- Create an [issue](https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/289) and update the [build calendar](https://calendar.google.com/calendar/u/0?cid=cHJmazI2ZmRtcHJ1MW1wdGxiMDZwMGpoNHNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ) for the next GA release based on the [Simultaneous Release schedule](https://wiki.eclipse.org/Simultaneous_Release).
- Each stream has its own [wiki](https://wiki.eclipse.org/Category:SimRel-2022-06) page with a more detailed schedule.
- List of people who can edit the calendar
Expand All @@ -123,9 +127,8 @@ The release is scheduled for 10AM EST. Typically the jobs are scheduled beforeha
- Sravan Kumar Lakkimsetti

#### **Update Splash Screen:**
- Create a tracking issue in [eclipse.platform](https://github.com/eclipse-platform/eclipse.platform) and link it to the main issue in eclipse.platform.releng.aggregator.
<!--TODO: mostly automted, just needs to be requested in advance. -->
- Future spash screens are kept in a subfolder of [eclipse.platform/platform/org.eclipse.platform](https://github.com/eclipse-platform/eclipse.platform/tree/master/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](https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues) similar to [Bug 575781](https://bugs.eclipse.org/bugs/show_bug.cgi?id=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](https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/2336)

Expand All @@ -135,28 +138,15 @@ The release is scheduled for 10AM EST. Typically the jobs are scheduled beforeha
- 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.
- Move the previous (still existing) I-Build job can be deleted (together with the associdated test jobs), when we are sure a RC respins won't happen anymore (probably best only after the release).

#### **Create Git Milestones for the next Release:**
#### **Run preparation for the next Release:**

Milestones are already created by running [`Prepare Next Development Cycle`](https://ci.eclipse.org/releng/job/Releng/job/prepareNextDevCycle/) 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`](https://ci.eclipse.org/releng/job/Releng/job/prepareNextDevCycle/) 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](cje-production) buildproperties.txt files
- **Set Previous Version to RC2**
- RC2 becomes the new baseline for the week before the GA release.
- Update previous-release.baseline in [eclipse-platform-parent/pom.xml](eclipse-platform-parent/pom.xml)
Run the [`Prepare Next Development Cycle`](https://ci.eclipse.org/releng/job/Releng/job/prepareNextDevCycle/) job, with suitable arguments
and check and submit the Pull-Requests created by it in the `eclipse.platform.releng.aggregator` repository and all its submodules.
<!-- TODO: describe the arguments? -->

**RC2a Release**
<!-- TODO: How does this work in detail? Use the old I-build jobs? -->
* 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.




Loading
Loading