Current main is CDT LSP 3.0 - which will be released with CDT 12 for Eclipse SimRel 2025-03

[jonahgraham]

With #410 the major version was bumped, but there are still some places that call the version 2.1 - such as

cdt-lsp/pom.xml

Line 17 in a2f4434

<version>2.1.0-SNAPSHOT</version>

• See also CDT 12.0.0 cdt#914

I am assigning this to myself to cleanup metadata, add milestones, etc ahead of the release.

This is the Release plan and TODO list for CDT LSP.

Steps for Release

Items at the beginning of development

• Create an Endgame Issue to track the release. As a starting point use RELEASING.md.
  • Add the Endgame label
• Create a New milestone for the release, and if available add a due date
  • Apply the milestone to the endgame issue
• Ensure all previous Endgame issues are done.
  • Make sure any previous edits made to Endgame issues of previous releases are updated in RELEASING.md
• Update version numbers on main branch (after the release branch was created), this is generally the next minor version (or major version if that is what the committers on the project agree) and applies to the following types of files:
  • feature.xml version
  • pom.xml version
  • It does not apply to versions in MANIFEST.MF which follow API rules.
• Ensure the CI build is stable - it is always better to release a "Green Dot" build

Items in the days ahead of Release day:

• Create release on PMI (e.g. 1.0.0 (CDT LSP))
  • Fill in the Review Documentation -> New & Noteworthy URL with the CHANGELOG.md
• Check CHANGELOG.md is up to date. The changelog should have a version entry, release date, API Breakages and other information consistent with current entries in the changelog.
• Check README.md is up to date, in particular:
  • the planned release and which versions of main dependencies are supported in the version support table
  • screenshots are up to date and consistent
  • try it out steps are correct and where suitable versions are up to date
• Check all closed PRs and Issues to make sure their milestone is set. This search may be useful to identify such closed issues
• Create a branch for the release
• Create the endgame for the next scheduled release right away and update the versions on the main branch

Items on Release day:

• Run the CI build for the branch
• Mark the build as Keep Forever and add the version to the description
• Create a GitHub releases page (like https://github.com/eclipse-cdt/cdt-lsp/releases/tag/CDT_LSP_1_0_0)
• Promote a cdt build from jenkins to releases
• 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/cdt-lsp-latest to point to latest release
• Tag the release. Example: git tag -a CDT_LSP_1_0_0 HEAD -m"CDT LSP 1.0.0" && git push origin CDT_LSP_1_0_0
• Create a release page on github
• Publish the GitHub release page
• Forward the GitHub release page email to cdt-dev

[jonahgraham]

Due to no changes between RC1 and release + a lack of time due to personal issues, the 3.0.0 release is being made from the main branch. The release content is the RC1 content promoted and the tags/new branch will reflect that.

[jonahgraham]

Other than the final release step, CDT LSP 3 is ready to go. Please see eclipse-cdt/cdt#914 (comment) for what is needed for that. Once that last step in eclipse-cdt/cdt#914 is done, this issue and eclipse-cdt/cdt#914 can be closed.

I have prepared the cdt_lsp_3_0 branch and main branch for development going forward, see #450 and #451 respectively.