CDT 11.4.0

[jonahgraham]

This is the Release plan and TODO list for the release in the title. CDT makes its simrel contribution on +1 day in the release cycle (normally Monday by 10pm UTC).

Steps for M1

Items before M1 +1 day:

• Create release on PMI
• Create a milestone on GitHub
• Create New and Noteworthy page for the release
• Prepare for the new release with all these updates: (Note: As I do this work I check the boxes, but I only check the top level one on this line once it is merged)
  • Update cdt.target to point to new dependency versions
  • Synchronize CDT.setup to cdt.target
  • cdt-baseline.target always refers to latest version of CDT. Change this if it isn't appropriate for a specific branch.
  • Add any new features released in latest to cdt-baseline.target
    • In the Problems view you can filter to see only This plug-in is not present in currently active API baseline. by choosing this error filter: "API Problems/Default API Baseline Problem". Ignore any test/example bundles.
  • Update help-docs-eclipserun-repo in root pom.xml and bump versions of all the docs plug-ins
  • Increment version of all feature.xml, pom.xml and any other place full version is used. (Easiest way is global find and replace, e.g. s/9.9.0/9.10.0/g and review changes.) (See bd814fd for a past example)
  • Update comparator.repo in root pom.xml to last release and if there have been any changes since the branch, bump versions of MANIFEST.MFs (If your local java version is the same as the docker container, or if you build in the docker container, a command line like mvn verify -DskipTests -P baseline-compare-and-replace -P build-standalone-debugger-rcp is good to test this has worked and nothing needs updating.)
  • Update Maven versions (check CI job)
  • Update simrel-site in root pom.xml
  • Remove old API error filters if they are no longer relevant. In the Problems view you can filter to see only these types of problems by selecting only "API Problems/Unused API Problem Filter Problem". (See 1048197 for a past example)
• Ensure the build is stable (on both Jenkins and GitHub actions) - it is always better to release a "Green Dot" build
• Ensure all previous Endgame issues are done.

Items on M1 +0 day:

• update cdt.target to most recent platform

Items on M1 +1 day:

• Run CQ license check and make sure no new CQs need to be filed - this does not need to be done for every milestone, but needs to be done if there are dependency changes.
• Promote a cdt build from jenkins
• Smoke test the release by installing it into platform's SDK build.
• Add description to the promote-a-build job and the job it promoted.
• Mark promoted job as Keep forever
• Using the CBI aggregator tooling update cdt.aggrcon. An example of a previous contribution is in gerrit
• Notify the cdt-dev list that the build was posted. Example on cdt-dev archives

Items on M1 +4 day (or shortly after):

• The final part of the release is to wait for announcement (normally on +4 day) like this on epp-dev and test the EPP build and confirm operation with a +1 to epp-dev mailing

Steps for M2

Items on M2 +0 day:

• update cdt.target to most recent platform

Items on M2 +1 day:

• Run CQ license check and make sure no new CQs need to be filed - this does not need to be done for every milestone, but needs to be done if there are dependency changes.
• Promote a cdt build from jenkins
  • if cdt.target has been updated to Platform M1, then STANDALONE can be checked, otherwise do it on +4
• Smoke test the release by installing it into platform's SDK build.
• Add description to the promote-a-build job and the job it promoted.
• Mark promoted job as Keep forever
• Using the CBI aggregator tooling update cdt.aggrcon. An example of a previous contribution is in gerrit
• Notify the cdt-dev list that the build was posted. Example on cdt-dev archives

Items on M2 +4 day (or shortly after):

• The final part of the release is to wait for announcement (normally on +4 day) like this on epp-dev and test the EPP build and confirm operation with a +1 to epp-dev mailing

Steps for M3

Items on M3 +0 day:

• update cdt.target to most recent platform

Items on M3 +1 day:

• Run CQ license check and make sure no new CQs need to be filed - this does not need to be done for every milestone, but needs to be done if there are dependency changes.
• Promote a cdt build from jenkins
  • if cdt.target has been updated to Platform M1, then STANDALONE can be checked, otherwise do it on +4
• Smoke test the release by installing it into platform's SDK build.
• Add description to the promote-a-build job and the job it promoted.
• Mark promoted job as Keep forever
• Using the CBI aggregator tooling update cdt.aggrcon. An example of a previous contribution is in gerrit
• Notify the cdt-dev list that the build was posted. Example on cdt-dev archives

Items on M3 +4 day (or shortly after):

• The final part of the release is to wait for announcement (normally on +4 day) like this on epp-dev and test the EPP build and confirm operation with a +1 to epp-dev mailing

Steps for RC1

Items before RC1 +1 day:

• Ensure there are no API errors

Items on RC1 +0 day:

• update cdt.target to most recent platform
• update dependencies in MANIFEST.MF to require that platform (see a1febf0 as an example)

Items on RC1 +1 day:

• Run CQ license check and make sure no new CQs need to be filed - this does not need to be done for every milestone, but needs to be done if there are dependency changes.
• Promote a cdt build from jenkins
  • if cdt.target has been updated to Platform M1, then STANDALONE can be checked, otherwise do it on +4
• Smoke test the release by installing it into platform's SDK build.
• Add description to the promote-a-build job and the job it promoted.
• Mark promoted job as Keep forever
• Using the CBI aggregator tooling update cdt.aggrcon. An example of a previous contribution is in gerrit
• Notify the cdt-dev list that the build was posted. Example on cdt-dev archives

Items on RC1 +4 day (or shortly after):

• The final part of the release is to wait for announcement (normally on +4 day) like this on epp-dev and test the EPP build and confirm operation with a +1 to epp-dev mailing

Steps for RC2

These steps should be done before RC2 release, they can be completed at anytime between the last branch creation/release and RC2.

Items before RC2 +1 day:

• Run CQ license check and make sure no new CQs need to be filed - this does not need to be done for every milestone, but needs to be done if there are dependency changes. Note it is probably too late to get a CQ resolved in time for release at this point, so consider mitigation too.
• Create branch for CDT release. Ideally we want to release from the branch.

Items on RC2 +0 day:

• update cdt.target to most recent platform
• update dependencies in MANIFEST.MF to require that platform (see a1febf0 as an example)

Items on RC2 +1 day:

• Run CQ license check and make sure no new CQs need to be filed - this does not need to be done for every milestone, but needs to be done if there are dependency changes.
• Promote a cdt build from jenkins
  • if cdt.target has been updated to Platform M1, then STANDALONE can be checked, otherwise do it on +4
• Smoke test the release by installing it into platform's SDK build.
• Add description to the promote-a-build job and the job it promoted.
• Mark promoted job as Keep forever
• Using the CBI aggregator tooling update cdt.aggrcon. An example of a previous contribution is in gerrit
• Notify the cdt-dev list that the build was posted. Example on cdt-dev archives

Items on RC2 +4 day (or shortly after):

• The final part of the release is to wait for announcement (normally on +4 day) like this on epp-dev and test the EPP build and confirm operation with a +1 to epp-dev mailing

Steps for Release

Items for quiet week (between RC2 and release):

• Ensure release entry on PMI "Release Date" section it says the appropriate "This release is part of Eclipse IDE ??????".
• Make sure documentation is part of simrel's help.
• Review closed issues and merged PRs to make sure labels and milestones are accurate
• Review the New and Noteworthy for content
• Create a GitHub releases page (like https://github.com/eclipse-cdt/cdt/releases/tag/CDT_11_1_0)

Items to be done 2 days before release:

• Promote a cdt build from jenkins to releases (run twice so standalone is promoted too if needed)
• Add description to the promote-a-build job and the job it promoted.
• Unmark as keep all old Milestone and RC jobs
• Update or create composites in preparation for going public on release day
  • Include the update to latest URL https://download.eclipse.org/tools/cdt/releases/latest/ to point to latest release

Release day:

• Verify we get a GO on the cross-project-issues-dev mailing list
• Promote the files to download - this makes the release public
• Tag the release. Example: git tag -a CDT_9_4_2 2cdc63eae52c8952c0d2543e1e31ca6e25225c4a -m"CDT 9.4.2" && git push origin CDT_9_4_2
• Update Downloads
• Update Marketplace entries:
  • https://marketplace.eclipse.org/content/complete-eclipse-cc-ide/edit (Complete C/C++ IDE)
  • https://marketplace.eclipse.org/content/eclipse-cc-ide/edit (CDT)
  • https://marketplace.eclipse.org/content/tm-terminal/edit (Terminal)
• Publish the GitHub release page
• Forward the GitHub release page email to cdt-dev
• Delete download.eclipse.org/tools/cdt/builds for this release
  • Visit https://archive.eclipse.org/tools/cdt/ and press login if the checkboxes and Archive button are not visible
  • Visit https://archive.eclipse.org/tools/cdt/ and delete "builds" if present
  • Visit https://download.eclipse.org/tools/cdt/ and archive "builds"
  • Optional visit https://archive.eclipse.org/tools/cdt/ and delete "builds"
• Using the CBI aggregator tooling update cdt.aggrcon to point to the release as it is not probably pointing to the cdt/builds directory. (e.g. https://git.eclipse.org/r/#/c/154853/)
• Review and discard any "kept forever" builds, especially milestone and superseded RC builds for cdt-master, and jobs on cdt-verify-test-cdt-other-pipeline that were kept around to be tested.
• Update help-docs-eclipserun-repo in root pom.xml (remove -I-builds from path) on the branch and main
• Update target platforms (remove -I-builds from path) on the branch and main

[jonahgraham]

main now looks good and is fully ready for CDT 11.4 development.

[jonahgraham]

Due to a mistake on my end we didn't contribute a new build for SimRel 2023-12 M2. Normal service expected to return for M3.