Release preview versions at a higher cadence

[o-l-a-v]

Summary of the new feature

Preview builds are beta, aka. no guarantees on stability. I'm totally fine with that.

But when major goof bugs appear, like the random "@" appearing in terminal after running PowerShell with the latest Preview version (2019.11) ref #2353, it should be possible to release fixes more frequently than once a month. There's even a fix for the "@" bug that's been reported multiple times now.

Proposed technical implementation details (optional)

I wish preview builds to be released at a higher cadence. A lot of important fixes are already there in code, but latest released build is over a month old now.

If major changes are still not considered stable enough for a new preview release, at least release bug fixing releases between the major ones. Like "2019.11.X", where X are minor changes like bug fixes.

[rjmholt]

This is likely covered by #2286.

Since investing in the rearchitecture work, our bandwidth has been too limited to allow us to invest in more streamlined release infrastructure. When we stablise the preview extension properly in January, we'll hopefully find time to make this investment, and the preview extension will become a true preview rather than the fork it is today.

It's worth noting that we can't fully automate our release process for non-technical reasons, so every release must have some overhead.

I should also mention that it's possible to get builds from CI:

You can get to this for any commit in master by clicking on the green tick or red cross in this screen.

Ultimately, we also want to invest in improvements here since we also have increased release cadence as a goal, it's just a matter of being able to do the work to lower the overhead enough to make it possible.

[andyleejordan]

I am committed to releasing more frequently, I'm going to mark this resolved. A lot of work has been done to make the release process smoother and therefore faster, though there's obviously more to do. It still takes about a day's commitment to generate the release, test it internally, sign off on it, and upload it to GitHub and the marketplace. Should start seeing previews pretty much any time I've completed a handful of work items, probably every two to three weeks, and we can certainly do releases "on-demand" when a major bug fix lands as I've changed the branch model such that "preview" is simply newer, less tested code than "stable" and so doesn't contain things we're not intending to release.