CDT LSP 1.1.0

[jonahgraham]

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

I don't know if we are going to do 1.1.0 next, but the master branch should be updated to 1.1.0 now (and may become 2.0.0 if we want to do a major version).

If we want to do a 1.0.1 version we should do that from the cdt_lsp_1_0 branch.

[jonahgraham]

@ghentschke thanks for all the work on getting the release out.

There is a minor error, the wrong commit was tagged as 1.1.0. It should have been commit de6e9a5 (the one built in https://ci.eclipse.org/cdt/job/cdt-lsp/job/cdt_lsp_1_1/2/) but it was the next one 5c2a608 (which is the version bump that was on main branch)

I think to resolve you can just add a comment in the release page, or try to delete the tag and recreate it:

git push origin :CDT_LSP_1_1_0
git tag -a CDT_LSP_1_1_0 de6e9a5cc8a6468441832cce5379191686c3d5f0 -m"CDT LSP 1.1.0" && git push origin CDT_LSP_1_1_0

But the protection rules will probably prevent you doing that, which means raising a helpdesk ticket

[travkin79]

Thank you, @ghentschke and @jonahgraham for quickly preparing the roll-out.

Unfortunately, checking the update sites, I found some additional issues.

• the update site for release 1.1.0 contains plug-ins with version 1.0.0 (see URL https://download.eclipse.org/tools/cdt/releases/cdt-lsp-1.1/cdt-lsp-1.1.0/plugins/)
  
• the update site for the latest release (mentioned in the README.md) does not contain any jar file. (see https://download.eclipse.org/tools/cdt/releases/cdt-lsp-latest)
  

It seems, the released version (commit de6e9a5) contains version 1.0.0 in the MANIFEST.MF files.

[ghentschke]

the update site for release 1.1.0 contains plug-ins with version 1.0.0

That's correct. The plugin version has not been incremented. I know that's a little irritating.

the update site for the latest release (mentioned in the README.md) does not contain any jar file.

That should be also OK, since the xml files pointing to ../cdt-lsp-1.1.

@jonahgraham Should the bundle version be incremented as well when we are not performing any API baseline checks?

[travkin79]

Ok. Thank you for clarification, @ghentschke. I didn't expect that. :-)

But thinking about plug-in dependencies, I think, the bundle version has to be incremented, since the build number is usually not used when describing plug-in dependencies, but plug-ins using the new API do need to specify a newer version than 1.0.0 in order to force Eclipse to update the cdt lsp plug-ins. I've expected the new bundle versions to be 1.1.0.x.

[iloveeclipse]

That's correct. The plugin version has not been incremented. I know that's a little irritating.

That is indeed irritating. Could you give a hint why it wasn't incremented? As @travkin79 mentioned, version increment is important to consumers that want force the minimum version range to be used.

[ghentschke]

Could you give a hint why it wasn't incremented?

I know that its not good practice. I simply forgot it. Unfortunately I forgot to tag the exported packages of the LSP plugin as provisional API as well. I will do that soon. That why we added this comment to the changelog.

[jonahgraham]

I've expected the new bundle versions to be 1.1.0.x.

FWIW the "correct" bundle versions should have been 1.0.100.qualifier for any bundles modified since 1.0.0. The qualifiers set from jgit + compare and replace are coming in the future.