CDT 9.10.0 Endgame

[jonahgraham]

This is the Release plan and TODO list for CDT 9.10.0 release, part of the Eclipse 2019-12 Simrel. 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 New and Noteworthy page for the release
• Update cdt.target to point to new dependency versions
• Synchronize CDT.setup to cdt.target
• Update API baseline to last release and resolve any API errors
• Remove old API error filters if they are no longer relevant
• Synchronize CDT.setup for API baseline
• 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.)
• Increment version URL in releng/org.eclipse.cdt-feature/p2.inf
• Increment version URL in EPP's packages/org.eclipse.epp.package.cpp.feature/p2.inf
• 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
• Update Maven versions (check CI job)
• Update simrel-site in root pom.xml
• Ensure the build is stable - it is always better to release a "Green Dot" build
• Ensure all previous Endgame issues are done.

Items on M1 +0 day:

• If tracking most recent platform, look for announcement and update cdt.target to M1 Eclipse Platform

Items on M1 +1 day:

• 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 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
• If standalone was not included on +1 day Promote a cdt build from jenkins to add the standalone build (STANDALONE_ONLY = true)
• Add description to the promote-a-build job and the job it promoted.
• Mark promoted job as Keep forever
• Reply to email sent on +1 day with links to EPP and standalone debugger. Example on cdt-dev archives.

Steps for M2

Items on M2 +0 day:

• If tracking most recent platform, look for announcement and update cdt.target to M2 Eclipse Platform

Items on M2 +1 day:

• Promote a cdt build from jenkins
  • if cdt.target has been updated to Platform M2, 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
• If standalone was not included on +1 day Promote a cdt build from jenkins to add the standalone build (STANDALONE_ONLY = true)
• Add description to the promote-a-build job and the job it promoted.
• Mark promoted job as Keep forever
• Reply to email sent on +1 day with links to EPP and standalone debugger. Example on cdt-dev archives.

Steps for M3

Items before M3 +1 day:

• Ensure release entry on PMI "Release Date" section it says the appropriate "This release is part of Eclipse IDE ??????".
• Schedule a release review if it is needed (generally >= 12 months since the last one). Consult EDP for guidance.

Items on M3 +0 day:

• If tracking most recent platform, look for announcement and update cdt.target to M3 Eclipse Platform

Items on M3 +1 day:

• Promote a cdt build from jenkins
  • if cdt.target has been updated to Platform M3, 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
• If standalone was not included on +1 day Promote a cdt build from jenkins to add the standalone build (STANDALONE_ONLY = true)
• Add description to the promote-a-build job and the job it promoted.
• Mark promoted job as Keep forever
• Reply to email sent on +1 day with links to EPP and standalone debugger. Example on cdt-dev archives.

Steps for RC1

Items before RC1 +1 day:

• Ensure there are no API errors

Items on RC1 +0 day:

• If tracking most recent platform, look for announcement and update cdt.target to RC1 Eclipse Platform

Items on RC1 +1 day:

• Promote a cdt build from jenkins
  • if cdt.target has been updated to Platform RC1, 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
• If standalone was not included on +1 day Promote a cdt build from jenkins to add the standalone build (STANDALONE_ONLY = true)
• Add description to the promote-a-build job and the job it promoted.
• Mark promoted job as Keep forever
• Reply to email sent on +1 day with links to EPP and standalone debugger. Example on cdt-dev archives.

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:

• Create branch for CDT release
• Create new Jenkinsfiles for new release and create jobs
• Make sure New and Noteworthy page is up to date

Items on RC2 +0 day:

• If tracking most recent platform, look for announcement and update cdt.target to RC2 Eclipse Platform

Items on RC2 +1 day:

• Promote a cdt build from jenkins
  • if cdt.target has been updated to Platform RC2, 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
• If standalone was not included on +1 day Promote a cdt build from jenkins to add the standalone build (STANDALONE_ONLY = true)
• Add description to the promote-a-build job and the job it promoted.
• Mark promoted job as Keep forever
• Reply to email sent on +1 day with links to EPP and standalone debugger. Example on cdt-dev archives.

Steps for Release

Items for quiet week (between RC2 and release):

• Make sure documentation is part of simrel's help.

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 cdt-infra in preparation for going public on release day

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 https://www.eclipse.org/cdt/ (current status) and https://www.eclipse.org/cdt/downloads.php
• Make an announcement on cdt-dev. Example on cdt-dev archives

Items after the release:

• Delete download.eclipse.org/tools/cdt/builds for this release (e.g:

# Keep a backup on archive temporarily
ssh build.eclipse.org rsync -aAXv /home/data/httpd/download.eclipse.org/tools/cdt/builds /home/data/httpd/archive.eclipse.org/tools/cdt
ssh build.eclipse.org mv -v /home/data/httpd/archive.eclipse.org/tools/cdt/builds/9.10 /home/data/httpd/archive.eclipse.org/tools/cdt/builds/9.10-scheduled-for-deletion
ssh build.eclipse.org rm -rv /home/data/httpd/download.eclipse.org/tools/cdt/builds/9.10 

• 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/)

[jonahgraham]

Remove old API error filters if they are no longer relevant

This wasn't done for 9.10, it is done for 9.11 (on master) already.

[jonahgraham]

That's it. CDT 9.10.0 is done.