Skip to content
This repository has been archived by the owner on Apr 30, 2024. It is now read-only.

CDT 10.7.0 #59

Closed
jonahgraham opened this issue Apr 10, 2022 · 1 comment
Closed

CDT 10.7.0 #59

jonahgraham opened this issue Apr 10, 2022 · 1 comment
Labels
endgame Checklist of TODO lists to finish a release

Comments

@jonahgraham
Copy link
Member

jonahgraham commented Apr 10, 2022 •
edited
Loading

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 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
    • Update API baseline to last release and resolve any API errors
    • 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.) (See this gerrit 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.)
      • 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
        • org.eclipse.cdt.debug.dap because it pulls and builds with yarn
    • 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 this gerrit for a past example)
  • 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:

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

Steps for M2

Items on M2 +0 day:

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 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

Steps for M3

Items before M3 +1 day:

  • Schedule a release or progress review if it is needed (generally >= 12 months since the last one). Consult EDP for guidance.

Items on M3 +0 day:

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 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

Steps for RC1

Items before RC1 +1 day:

  • Ensure release entry on PMI "Release Date" section it says the appropriate "This release is part of Eclipse IDE ??????".
  • Ensure there are no API errors

Items on RC1 +0 day:

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. Note it is probably too late to get a CQ resolved in time for release at this point, so consider mitigation too.
  • 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

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
  • Create new Jenkinsfiles for new release and create jobs
  • Make sure New and Noteworthy page is up to date

Items on RC2 +0 day:

Items on RC2 +1 day:

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):

Items to be done 2 days before release:

Release day:

Items after the release:
@jonahgraham jonahgraham added the endgame Checklist of TODO lists to finish a release label Apr 11, 2022
@jonahgraham jonahgraham modified the milestone: CDT 10.2.0 Apr 11, 2022
@jonahgraham
Copy link
Member Author

Done with CDT 10.7.0 - just email left to press send on.

This was referenced Aug 14, 2022
Closed
Merged
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
endgame Checklist of TODO lists to finish a release
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@jonahgraham