From f0a543fc46303e82db6aab53ca460d17749fddbb Mon Sep 17 00:00:00 2001 From: Hannes Wellmann Date: Thu, 26 Feb 2026 18:37:32 +0100 Subject: [PATCH] Adapt Release and RelEng documentation to reworked release automation Update the main preparation PR to include all remaining steps and to include further instructions. The main preparation PR in this repository then also acts as replacement for the issue tracking the preparation. --- .../Releng/prepareNextDevCycle.jenkinsfile | 16 ++++- RELEASE.md | 70 ++++++++----------- RELENG.md | 42 +++++++---- scripts/GAReleasePrep.sh | 11 ++- scripts/newReleasePrep.sh | 48 ------------- 5 files changed, 84 insertions(+), 103 deletions(-) delete mode 100755 scripts/newReleasePrep.sh diff --git a/JenkinsJobs/Releng/prepareNextDevCycle.jenkinsfile b/JenkinsJobs/Releng/prepareNextDevCycle.jenkinsfile index 828195eff82..95bb7e0086e 100644 --- a/JenkinsJobs/Releng/prepareNextDevCycle.jenkinsfile +++ b/JenkinsJobs/Releng/prepareNextDevCycle.jenkinsfile @@ -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 -> diff --git a/RELEASE.md b/RELEASE.md index 0721a59695f..fe424ed7947 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -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) @@ -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. + + - 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). @@ -59,46 +62,35 @@ 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. @@ -106,12 +98,24 @@ The release is scheduled for 10AM EST. Typically the jobs are scheduled beforeha - 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. + + + * **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. + #### **Update the Build Calendar:** + - 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 @@ -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. + - 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) @@ -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. + **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. - - - - diff --git a/RELENG.md b/RELENG.md index b97cf4694fd..5f18a06e802 100644 --- a/RELENG.md +++ b/RELENG.md @@ -2,18 +2,18 @@ ## **Job Creation with Job DSL** -**Create Jobs** +### **Create Jobs** -The (Create Jobs)[https://ci.eclipse.org/releng/job/Create%20Jobs/] job is used to populate the jenkins subfolders with the jobs defined in (JenkinsJobs)[JenkinsJobs] groovy files. There are 2 Process Job DSLs steps, the first looks for FOLDER.groovy files and creates the folders, the second creates the jobs themselves. +The (Create Jobs)[https://ci.eclipse.org/releng/job/CreateJobs/] job is used to populate the jenkins subfolders with the jobs defined in (JenkinsJobs)[JenkinsJobs] groovy files. There are 2 Process Job DSLs steps, the first looks for FOLDER.groovy files and creates the folders, the second creates the jobs themselves. Create Jobs *must be run manually*. Unfortunately JobDSL needs to be run by a specific user, so the build cannot be automatically started by a timer or when it detects jenkins changes without installing an additional plugin like (Authorize Project)[https://plugins.jenkins.io/authorize-project/], which supposedly still works but is abandoned and I (Sam) have not had time to investigate further or find alternatives. This means that while any committer can make changes to the Jenkins Jobs in git, someone with Jenkins rights will have to start the build to implement those changes. Obsolete jobs have to be deleted manually. They are not deleted automatically as some may be are still in use for a short time (e.g. Y-builds if a java-release is imminent) or to serve as reference in case the new jobs have problems. -**The JenkinsJobs Folder** +### **The JenkinsJobs Folder** -As a general rule, the (JenkinsJobs)[JenkinsJobs] folder should match the layout of Jenkins itself. Every subfolder should contain a (FOLDER.groovy)[JenkinsJobs/Builds/FOLDER.groovy] file as well as groovy files for all individual jobs. +As a general rule, the (JenkinsJobs)[JenkinsJobs] folder should match the layout of Jenkins itself. Every subfolder should contain a (FOLDER.groovy)[JenkinsJobs/Builds/FOLDER.groovy] file as well as groovy files for all individual jobs. Note: JobDSL does also support the creation of Views, so those can be added at some point but someone will either have to manually keep them up to date with the desired jobs or write a script to keep them up-to-date. @@ -21,27 +21,45 @@ Many jobs have the release version in the job name because it is required for re In order to minimize manual labor the currently active streams are listed in the (buildConfigurations.json)[JenkinsJobs/buildConfigurations.json] file. Version dependent jobs then parse this file during creation and make a job for each stream. -**New Jobs** +### **New Jobs** Adding a job to Jenkins should be as easy as adding a new groovy file to git, but here are some general pointers. * **No dashes in filenames**, it breaks JobDSL. If there was a `-` in the job name I changed it to `_` in the file name. * **Job Names** - - No spaces, this is just for the good of scripts etc. The job NAME is used in the url, but you can always add a `displayName` field if you want the job to appear with a more natural looking name on the page. See (Releng/deployToMaven)[JenkinsJobs/Releng/FOLDER.groovy] as an example. - - The folder needs to be part of the job name, otherwise Jenkins will just create the job at the dashboard level. + - No spaces, this is just for the good of scripts etc. The job NAME is used in the url, but you can always add a `displayName` field if you want the job to appear with a more natural looking name on the page. + See (Releng/deployToMaven)[JenkinsJobs/Releng/FOLDER.groovy] as an example. + - Jenkins files should use CamelCase Naming but the corresponding job names should use dash-case for better readabliliy of the resulting URLs. In the display name composed names should be separated by spaces. + #TODO: Consisistently apply this! + - The folder needs to be part of the job name, otherwise Jenkins will just create the job at the dashboard/top level. * **job vs pipelineJob** - - Anything that can build on a regular jenkins node or via an available lable uses the (job)[https://jenkinsci.github.io/job-dsl-plugin/#path/job] template. - - Anything that defines its own kubernetes pod needs to be a (pipelineJob)[https://jenkinsci.github.io/job-dsl-plugin/#path/pipelineJob] -* **Script Formatting** You can use `'''`triple apostrophes`'''` to define multiline scripts. I've found it's best to start the script on the same line and not the next, otherwise you end up with blank space at the top of the script step in Jenkins which can break the build (like the arm64 smoke tests). + - Generally pipelineJobs defined an dedicated jenkinsfile are prefered as they are more powerful and simpler to modify and manage, defining Jenkins _Freestyle_ jobs is discouraged. +* **Script Formatting** You can use `'''`triple apostrophes`'''` to define multiline scripts. It's best to append a back-slash to prevent a blank line at the top of the script step in Jenkins. * To see what plugins are installed and what methods are available in the Releng Jenkins you can consult the (api viewer)[https://ci.eclipse.org/releng/plugin/job-dsl/api-viewer/index.html#]. +### **Testing new Jobs or trying out changes before production** + +Just like regular code, new changes or changes on jobs should be tested in a 'testing' environment before put into production. +As we don't have a dedicated testing environment, the regular [RelEng Jeninks](https://ci.eclipse.org/releng/) has to be used, +but one can use a 'testing' copy of the final job that doesn't have any effect on the production environment. +A testing job has to be created manually in the Jenkins UI and will only exist temporarily for the time of the testing. +It's recommended to put your name in the job name in order to help others, to identify the person to ask if that job is still relevant, in case you forgot to clean it up. +In the testing job you can use another source for the Jenkins file, for example your fork of this repo and another branch. + +** Make sure your testing job does not have an effect on the production environment** + +'Disable' all steps that have any effect on the production environment or redirect them to a testing environment too +- Disable `git push`. Use `--dry-run` or comment out +- Disable modification at the download server via `ssh` or `scp` or redirect changes to a 'try-out' area hidden from the public + - Some jobs already have a `DRY_RUN` parameter that deploy to `https://download.eclipse.org/eclipse/try-outs/`. +- Don't send mails to mailing lists via the `emailext` step, instead just send a mail to your private mail directly. # Updating Java Versions -Every 6 months there is a new Java release which requires additional builds and testing. The java release usually corresponds to odd numbered streams so a new java version would be tested in additional builds run during the 4.25 stream and then included in the 4.26 release I-builds. +Every 6 months there is a new Java release which requires additional builds and testing. The java release usually corresponds to odd numbered streams so a new java version would be tested in additional builds run during the 4.25 stream and then included in the 4.26 release I-builds. ## **Y and P Builds** -The **Y-build** is a full sdk build with the new java version for testing. +The **Y-build** is a full sdk build with the new java version for testing. The **P-build** is a patch build that contains modified plugins designed to be installed on top of the current I-build to test the new java version. They are now managed by the JDT-project itself in (org.eclipse.jdt.releng)[https://github.com/eclipse-jdt/eclipse.jdt/tree/master/org.eclipse.jdt.releng]. diff --git a/scripts/GAReleasePrep.sh b/scripts/GAReleasePrep.sh index 1766cd91b30..44282cca76f 100755 --- a/scripts/GAReleasePrep.sh +++ b/scripts/GAReleasePrep.sh @@ -26,14 +26,21 @@ TITLE="Release ${STREAM}" BODY="Umbrella bug to track release activities for ${STREAM} For previous bug please refer to eclipse-platform/eclipse.platform.releng.aggregator#${PREV_ISSUE}. - +// TODO: mention the jobs to run here and when to run them exactly? Or just in the general doc. And add links to the items in the general doc here with current commit-ids?! - [ ] Readme file for ${STREAM} - [ ] ${STREAM} Acknowledgements + Just submit the generated PR. - [ ] Migration Guide - [ ] SWT Javadoc bash for ${STREAM} - [ ] Publish ${STREAM} to Maven central + - Should be done one day before the release to ensure everything is mirrored at the time of release - [ ] Contribute ${STREAM} to SimRel -- [ ] Clean up intermediate artifacts (milestones, I-builds and old releases) + - Should be done one day before the release to the SimRel aggregation does not contain the RC I-build repo deleted on release day. + +- Preparation of the subsequent development cycle + - [ ] Run [`Prepare Next Development Cycle`](https://ci.eclipse.org/releng/job/Releng/job/prepareNextDevCycle/) job and submit the created changes + - Run the preparation after RC1? RC2 would be build from maintenance branches + - [ ] Run it with final parameters as `dry-run` (ideally a day) before and verify correctnes. @notifications: @SDawley, @lshanmug, @SarikaSinha, @ktatavarthi, @niraj-modi diff --git a/scripts/newReleasePrep.sh b/scripts/newReleasePrep.sh deleted file mode 100755 index a2ff7a38dc6..00000000000 --- a/scripts/newReleasePrep.sh +++ /dev/null @@ -1,48 +0,0 @@ -#! /bin/bash - -Help () { - echo " - Usage: $0 -v NEXT_STREAM -t NEXT_TRAIN -i PREVIOUS_RELEASE_ISSUE -p PREVIOUS_STREAM - Example: $0 -v 4.25 -t 2022-09 -i 48 -p 4.24 - " - exit -} - -if [[ $# -lt 4 ]]; then Help; exit; fi - -while [[ "$#" -gt 0 ]]; do - case $1 in - '-v') NEXT_STREAM=$(echo $2|tr -d ' '); shift 2;; - '-t') NEXT_TRAIN=$(echo $2|tr -d ' '); shift 2;; - '-i') PREV_ISSUE=$(echo $2|tr -d ' '); shift 2;; - '-p') PREV_MAJOR="${2%.*}"; PREV_MINOR="${2#*.}"; shift 2;; - '-h') Help; exit;; - esac -done - -TITLE="Preparation work for ${NEXT_STREAM} (${NEXT_TRAIN}) and open master for development" - -BODY="This preparation work involves the following tasks. For previous bug please refer to eclipse-platform/eclipse.platform.releng.aggregator#${PREV_ISSUE}. - -- [ ] Update JenkinsJobs for ${NEXT_STREAM}: -- - [ ] Add ${NEXT_STREAM} to `buildConfigurations.json` to create new jobs -- - [ ] Update "Brances" in `buildConfigurations.json` to move ${PREV_MAJOR}.${PREV_MINOR}-I builds to R${PREV_MAJOR}_${PREV_MINOR}_maintenance branch -- - [ ] Update I-build triggers with dates for ${NEXT_STREAM} milestone -- [ ] Splash Screen for ${NEXT_STREAM} (${NEXT_TRAIN}) -- [ ] Create ${NEXT_STREAM}-I-builds repo -- [ ] Run [`Prepare Next Development Cycle`](https://ci.eclipse.org/releng/job/Releng/job/prepareNextDevCycle/) job and submit the created changes -- [ ] Update version number in Mac's Eclipse.app for ${NEXT_STREAM} -- [ ] Update builds and repo cleanup scripts for ${NEXT_STREAM} -- [ ] Update check composites script to verify ${NEXT_STREAM} repositories -- [ ] Update Comparator repo and eclipse run repo to ${NEXT_STREAM}-I-builds repo -- [ ] Version bumps for ${NEXT_STREAM} stream -- [ ] Update previous release version to ${PREV_MAJOR}.${PREV_MINOR} GA across build scripts -- [ ] Update build calendar for platform ${NEXT_STREAM} release -- [ ] Deploy ecj compiler from ${PREV_MAJOR}.${PREV_MINOR} GA and use it for ${NEXT_STREAM} M1 build -- [ ] Update generic repos I-builds, Y-builds, P-builds to point to ${NEXT_STREAM} repos -" - -echo "Creating Issue $TITLE" -echo "$BODY" - -gh issue create --title "$TITLE" --body "$BODY" --assignee @me