Release Pipeline

[jpoon]

We need a better (ie. automated) way of releasing a new version. Right now the steps are:

1. Get latest code (git pull) and ensure that the builds pass (check Travis)
2. gulp release to update the package version and git push --follow-tags
3. vsce package
4. vsce publish
5. Go to GitHub and update the releases page
6. upload the vsix from step 3 to the releases page

Suggestion:

It'd be great if we could automate all 6 of those steps. However, as vsce publish requires a login/key, it's not something we want to put publicly in our repo.

I think we can still automate steps 2, 3, and 6.

1. We have a releases branch where a merge/commit to that branch will start some CI build.
2. Travis supports GitHub releases so we can get the CI to update the package version (2), vsce package (3), and auto-upload that to GitHub (6)

[jpoon]

If this gets implemented, it would also eliminate step 2.

[johnfn]

I'm fine with this, though since I do releases so infrequently it's never been a big pain point. I totally didn't know about uploading the vsix file on the github page though, that's clever.

While we're on the topic of releases, I think we should abandon our current versioning scheme and instead start incrementing the minor every time we add features and the patch every time we do a hotfix. I kinda messed this one up. So next release will be 0.2.0, then 0.3.0 etc.

[jpoon]

You can pass in a personal access token: vsce publish -p <token> and Travis supported encrypted environment variables so building this pipeline should be do-able.