8000 CDT 11.0.0 · Issue #77 · eclipse-cdt/cdt · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
CDT 11.0.0 #77
New issue
New issue
Closed
Closed
CDT 11.0.0#77
Assignees
jonahgraham
Labels
endgameSteps to prepare, build and release CDT
Milestone
 
11.0.0
@jonahgraham

Description

@jonahgraham
jonahgraham
opened on Sep 30, 2022

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

Items on M1 +1 day:

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

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.

Items to be done 2 days before release:

Release day:

Metadata

Metadata

Assignees

Labels

endgameSteps to prepare, build and release CDT

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions
    0