2019.9 release plan

[brettcannon]

Prerequisites

• Python 3.7 and higher
• run python3 -m pip install --user -r news/requirements.txt
• run python3 -m pip install --user -r tpn/requirements.txt

Release candidate (Tuesday, Aug 27)

• Ensure all new features are tracked via telemetry
• Announce the code freeze (not just to team but also to ptvsd and language server)
• Update master for the release
  • Create a branch against master for a pull request
  • Change the version in package.json from a -dev suffix to -rc
  • Run npm install to make sure package-lock.json is up-to-date
  • Update requirements.txt to point to latest release version of ptvsd.
  • Update languageServerVersion in package.json to point to the latest version (???) of the Language Server.
  • Update CHANGELOG.md
    • Run news (typically python news --final --update CHANGELOG.md | code-insiders -)
    • Copy over the "Thanks" section from the previous release
    • Make sure the "Thanks" section is up-to-date (e.g. compare to versions in requirements.json)
    • Touch up news entries (e.g. add missing periods)
    • Add any relevant news entries for ptvsd and the language server if they were updated
  • Update ThirdPartyNotices-Distribution.txt by running tpn (typically python tpn --npm package-lock.json --npm-overrides package.datascience-ui.dependencies.json --config tpn/distribution.toml ThirdPartyNotices-Distribution.txt)
    • for each failure:
      1. go to the repo (from link on NPM page) and look for the license there
      2. copy the text from the failure into tpn/distribution.toml
      3. fill in the license found in the package's repo
    • if there is no license in a package's repo then do one of the following:
      • check the NPM metadata and fill in the corresponding license from the OSI site
      • ask the package maintainer (e.g. via github)
      • ask CELA
  • Update ThirdPartyNotices-Repository.txt as appropriate
  • Create a pull request against master
  • Merge pull request into master
• Update the release branch
  • (if necessary) Request from a repo admin that the branch be un-"protected"
  • Delete the release branch in the repo
  • Create a new release branch from master
  • (alternately, force-push the master branch to the GitHub "release" branch)
  • (if necessary) Request that the branch be set anew as "protected"
• Update master post-release
  • Bump the version number to the next monthly ("YYYY.M.0-dev") release in the master branch
    • package.json
    • package-lock.json
  • Create a pull request against master
  • Merge pull request into master
• Announce the code freeze is over
• Update Component Governance (Click on "microsoft/vscode-python" on that page)
  • Provide details for any automatically detected npm dependencies
  • Manually add any repository dependencies
• GDPR bookkeeping (@brettcannon)
• Open appropriate documentation issues
  • new features
  • settings changes
  • etc. (ask the team)
• Begin drafting a blog post
• Ask CTI to test the release candidate

Final (Tuesday, Sep 03)

Preparation

• Make sure the appropriate pull requests for the documentation -- including the WOW page -- are ready
• final updates to the release branch
  • Create a branch against release for a pull request
  • Update the version in package.json
  • Run npm install to make sure package-lock.json is up-to-date (the only update should be the version number if package-lock.json has been kept up-to-date)
  • Update CHANGELOG.md
    • Update version and date for the release section
    • Run news and copy-and-paste new entries (typically python news --final | code-insiders -; quite possibly nothing new to add)
  • Update ThirdPartyNotices-Distribution.txt by running tpn (typically python tpn --npm package-lock.json --npm-overrides package.datascience-ui.dependencies.json --config tpn/distribution.toml ThirdPartyNotices-Distribution.txt; quite possible there will be no change)
  • Update ThirdPartyNotices-Repository.txt manually if necessary
  • Create pull request against release
  • Merge pull request into release
• Make sure component governance is happy

Release

• Publish the release via Azure DevOps
  • Make sure CI is passing
  • Make sure the "Upload" stage on the release page succeeded
  • Make sure no extraneous files are being included in the .vsix file (make sure to check for hidden files)
  • Deploy the "Publish" stage
• Publish documentation changes
• Publish the blog post
• Determine if a hotfix is needed
• Merge release back into master

Clean up after this release

• Go through info needed issues and close any that have no activity for over a month
• GDPR bookkeeping

Prep for the next release

• Create a new release plan
• (Un-)pin release plan issues

[AeneasZhu]

Will Candidate version be pushed through insider channel to users earlier than stable version?

[brettcannon]

@AeneasZhu we won't be pushing RCs explicitly; the insiders program is built from master and our releases are simply a branch off master at some point to help stabilize for some extra testing and to make it easier to coordinate things like doc updates. Otherwise the RC window is so short and basically perpetually behind master it isn't worth making it available on insiders.

[AeneasZhu]

@brettcannon You mean the RC won't be published on Azure DevOps too? What if I want to try the next update's new feature in advance of stable version?

[brettcannon]

@AeneasZhu No, the release .vsix is always published via AzDO to our blob storage account, we just aren't bothering to provide an automated way to update the extension only to RCs.

[kimadeline]

New release plan: #7184