Release Activities Checklist

Dev Builds

• Grab the latest release from our nightly or create your own (see Creating A Signed Build instructions for more details)
• Draft a new release on GitHub, with attached binaries
  • name: 7-15-2015 Dev Build
  • tag: v1.1.Dev-7.15.2015
  • mark as: pre-release
  • description: replace the "important text" and commit tag below with relevant info

**Include any important text we want people to see here**

See source code history for information about recent fixes.

This release is based on a4cd399. It has been signed and virus scanned, but has not been extensively tested and is not recommended for production environments.

Please [report any bugs](http://github.com/Microsoft/nodejstools/issues) that you find in this build, and include the filename of the installer you used in your report.

You can also [build NTVS](https://github.com/microsoft/nodejstools/wiki/Build-Instructions) from the latest sources.

• Include any other notes as you see fit - call out any features/fixes that we really want to get feedback on, any dependencies (e.g. pre-release versions of VS)
• Update closed issues that were affected by this release with a link to http://github.com/Microsoft/nodejstools/releases - this makes it easy for us to get feedback on the release.

Major releases (alpha, beta, rc, rtm)

• Update marketing and VSCOM at least a week or two before if we want to enlist any help from them (even more if we are aligning with a major release). This includes
  • Visual Studio blog
  • Twitter / social media
  • In-product news item
  • Press releases
  • visualstudio.com page
• Touch base with relevant partner teams
• Kick off a signed build with the appropriate name. See Creating A Signed Build instructions for more details.
• Update the matrix and execute a manual test pass Manual Test Matrix
• Investigate any unit test failures and make sure they are not critical
• Set up bug bashes over the couple weeks prior so that we can make sure to keep a pulse on quality, and push the release back as necessary.
• Update documentation, videos, etc. (most important for RTM releases and any new features)
• Release Notes:
  • copy and paste the markdown from an existing release note to get started
  • change the release names
  • change the links to the binary locations to point to new aka.ms links - these links should point to the msi binary locations, not redirect to the VS gallery page.
  • Write a little about each feature in the release - this should be enough information to get people started with any new features. If we find that the description is getting long, then create full fledged docs for it. Think of this as part download page, part blog post, part docs (because let's be honest, we probably didn't get the chance to write those up yet 😉)
  • update contributors section and known issues section with relevant info
  • update other fields. e.g.
    • alpha, beta, rc
      • name: NTVS 1.1 RC2
      • tag: v1.1.RC2
      • mark as: pre-release
    • rtm
      • name: NTVS 1.1
      • tag: v1.1
  • save as a draft and email ntvscore for feedback
• Upload binaries to VS Gallery
• Verify all the download links are working and flip the switch on the release notes page
  • if this is a major release or an aligned release, this'll happen with on a Skype call so we can coordinate activities
• Update the the following links:
  • http://aka.ms/ntvslatest - this should point to the release notes for the most recent major version, and is the link that should be tweeted out and referenced in blog posts. Never link to an old release because we want people on the latest even if they discover an old post.
  • http://aka.ms/getntvs - this should point to the binary for the most recent RTM version of NTVS (with some exceptions)
• Update readme.md to point to new downloads
• TELL EVERYONE ABOUT IT!!! 🎉