CDT 11.0.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:

• [x] Create release on PMI
• [x] Create a milestone on GitHub
• [x] Create New and Noteworthy page for the release
• [x] 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)
  • [x] Update cdt.target to point to new dependency versions
  • [x] Synchronize CDT.setup to cdt.target
  • [x] cdt-baseline.target always refers to latest version of CDT. Change this if it isn't appropriate for a specific branch.
  • [x] 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.
  • [x] Update help-docs-eclipserun-repo in root pom.xml and bump versions of all the docs plug-ins
  • [x] 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 https://github.com/eclipse-cdt/cdt/commit/bd814fdaf90fc152f758604e07dfb7996e2f0f96 for a past example)
  • [x] 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.)
  • [x] The following need their bundle service segment updated all the time for various reasons:
    • [ ] org.eclipse.cdt.debug.application because the version number is encoded in the bundle
  • [ ] Update Maven versions (check CI job)
  • [x] Update simrel-site in root pom.xml
  • [x] 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 https://github.com/eclipse-cdt/cdt/commit/104819751ca24b85d1636322bb4132c38ea5ed30 for a past example)
• [x] Ensure the build is stable (on both Jenkins and GitHub actions) - it is always better to release a "Green Dot" build
• [x] Ensure all previous Endgame issues are done.

Items on M1 +0 day:

• [x] 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.
• [x] Promote a cdt build from jenkins
• [x] Smoke test the release by installing it into platform's SDK build.
• [x] Add description to the promote-a-build job and the job it promoted.
• [x] Mark promoted job as Keep forever
• [x] 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:

• [x] 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.
• [x] 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
• [x] Smoke test the release by installing it into platform's SDK build.
• [x] Add description to the promote-a-build job and the job it promoted.
• [x] Mark promoted job as Keep forever
• [x] 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:

• [x] 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.
• [x] 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
• [x] Smoke test the release by installing it into platform's SDK build.
• [x] Add description to the promote-a-build job and the job it promoted.
• [x] Mark promoted job as Keep forever
• [x] 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:

• [x] update cdt.target to most recent platform
• [ ] update dependencies in MANIFEST.MF to require that platform (see https://github.com/eclipse-cdt/cdt/commit/a1febf009712cf7190b75519e8d610206e540009 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.
• [x] 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
• [x] Smoke test the release by installing it into platform's SDK build.
• [x] Add description to the promote-a-build job and the job it promoted.
• [x] Mark promoted job as Keep forever
• [x] 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:

• [x] update cdt.target to most recent platform
• [x] update dependencies in MANIFEST.MF to require that platform (see https://github.com/eclipse-cdt/cdt/commit/a1febf009712cf7190b75519e8d610206e540009 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.
• [x] 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
• [x] Smoke test the release by installing it into platform's SDK build.
• [x] Add description to the promote-a-build job and the job it promoted.
• [x] Mark promoted job as Keep forever
• [x] 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):

• [x] Ensure release entry on PMI "Release Date" section it says the appropriate "This release is part of Eclipse IDE ??????".
• [x] Make sure documentation is part of simrel's help.

Items to be done 2 days before release:

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

Release day:

• [x] Verify we get a GO on the cross-project-issues-dev mailing list
• [x] Promote the files to download - this makes the release public
• [x] Tag the release. Example: git tag -a CDT_9_4_2 2cdc63eae52c8952c0d2543e1e31ca6e25225c4a -m"CDT 9.4.2" && git push origin CDT_9_4_2
• [x] Update Downloads
• [x] Update Marketplace entries:
  • [x] https://marketplace.eclipse.org/node/3799227/edit (Complete C/C++ IDE)
  • [x] https://marketplace.eclipse.org/node/1373403/edit (CDT)
  • [x] https://marketplace.eclipse.org/node/1687099/edit (Terminal)
• [x] Make an announcement on cdt-dev. Example on cdt-dev archives
• [x] Delete download.eclipse.org/tools/cdt/builds for this release
  • [x] Visit https://archive.eclipse.org/tools/cdt/ and press login if the checkboxes and Archive button are not visible
  • [x] Visit https://archive.eclipse.org/tools/cdt/ and delete "builds" if present
  • [x] Visit https://download.eclipse.org/tools/cdt/ and archive "builds"
  • [ ] Optional visit https://archive.eclipse.org/tools/cdt/ and delete "builds"
• [x] 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/)
• [x] 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.
• [x] Update help-docs-eclipserun-repo in root pom.xml (remove -I-builds from path) on the branch and main
• [x] Update target platforms (remove -I-builds from path) on the branch and main

[jonahgraham]

As discussed at our last call, I planned to prepare a draft release with plenty of time before the CDT 11.0.0 release.

The release is next Wednesday (Dec 7th).

Committers should be able to see the CDT 11.0.0 draft release here: https://github.com/eclipse-cdt/cdt/releases (please edit as you see fit, but do not publish it). PS I can't confirm that anyone else can see it, perhaps only I can see the draft?

In addition I added a link to a GitHub search for noteworthy issues and PRs to the N&N document: https://github.com/eclipse-cdt/cdt/blob/main/NewAndNoteworthy/CDT-11.0.md#noteworthy-issues-and-pull-requests

Please comment here on the issue with your thoughts.

[jld01]

Hi @jonahgraham, do you think it's preferable/valuable to list the full set of PRs for milestone 11.0.0 on the release anouncement page as opposed to just the noteworthy PRs? Many of the non-noteworthy PRs will be of little interest to typical readers of the announcement. A counterargument is that every PR represents someone's effort towards the release and should be recognized.

[jonahgraham]

I had a similar thought - I like the autogenerated part(0), especially the New Contributors section(1). But I found it to be of little value(2), which is why I hid it behind the collapsible section(3).

(0) I imagine that as GitHub evolves the autogeneration will get more interesting too.

(1) In this release the "new contributors" section is a little off because we just moved to GitHub. You, me and @Torbjorn-Svensson aren't listed because we are listed in the 10.7.1 release page

(2) I agree with you about the value of recognizing someone's contribution. It can be a nice ego boost to see your name/contribution listed up front like that. The other value is it shows life of the project a little, similar purpose to the charts on PMI

PS I don't want to spend time manually maintaining a list. I think it is the auto-generated list, a link to the search, or I copy and paste the N&N into the release page.

[jonahgraham]

Update or create composites in preparation for going public on release day

I made a mistake in the above step, which is fixed in fb081b99759c77686ec51eca04bd89d577c36c83 but there is caching on download.eclipse.org which the p2 repo will present as slightly broken until the caches catch up.

They seem to be caught up for me already, but the GitHubActions seems to be seeing the old versions

[jonahgraham]

CDT 11.0.0 is done, onto CDT 11.1.0 in #202

PS. If we need a CDT 11.0.1 we can create that at short notice.