Skip to content

CDT LSP 3.2.0 #482

Open
Open
@jonahgraham

Description

@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.
  • 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.
  • 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. For example 3.1.0.qualifier becomes 3.2.0.qualifier.
    • pom.xml version. For example 3.1.0-SNAPSHOT becomes 3.2.0-SNAPSHOT.
    • MANIFEST.MF version, which follow API rules.
      This generally means updating the patch segment of the version by 100. For example 3.0.200.qualifier becomes 3.0.300.qualifier.
    • cdt-baseline.target baseline version, in coordination with the main CDT repo.
    • CDT.setup baseline version, in coordination with the main CDT repo.
  • 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
  • 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
  • Promote a cdt build from jenkins to releases
  • Add description to the promote-a-build job and the job it promoted.
  • Update or create composites in preparation for going public on release day
  • Test the build (before making it visible on the next step).
    In addition to normal smoke tests, make sure that updates work by adding the new p2 URL to available update sites in an instance of the last released Eclipse for C/C++ Developers and running Check for Updates. Since the composites have not been published yet, you need to add the p2 URL for the specific build, e.g. https://download.eclipse.org/tools/cdt/releases/cdt-lsp-3.1/cdt-lsp-3.1.0/
  • Run the job that updates the composites on https://download.eclipse.org/tools/cdt/releases/
  • Test the Check for Updates on a clean install to make sure that the https://download.eclipse.org/tools/cdt/releases/cdt-lsp-latest/ URL works.
    Caching on download.eclipse.org and p2 within Eclipse can sometimes really interfere at this stage as you can get different results to the web browser than in Eclipse, leading to confusion such as seeing the correct values in the browser, but no updates available in the IDE. Try leaving it for 30 minutes and restart Eclipse to see if it resolves itself, if it doesn't you may need to raised a IT helpdesk ticket for assistance.
  • Update the SimRel cdt.aggrcon file if appropriate. See this PR for a past example and https://github.com/eclipse-simrel/ for instructions on contributing to SimRel.
  • Unmark as keep all old Milestone and RC jobs
  • Create a release page on github using past releases pages as a guide of what to include.
    • Check all the links in the release page to make sure they work
  • Check the "Create a discussion for this release" and click Publish the GitHub release page
  • Forward the GitHub release page email to cdt-dev

Metadata

Metadata

Assignees

No one assigned

    Labels

    endgameSteps to prepare, build and release CDT LSP

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions