Release Cutting

[BenjamenMeyer]

Proposal:

• Master gets a regular (monthly/weekly) cut as an alpha release.
• Active Release branch(es) gets regular (PR/weekly) as a beta release

This should enable us to have some better confidence in releases as we get close to cutting a full release,and give folks more time to test them.

[stephengtuggy]

If we do this, who would be in charge of the weekly/monthly releases? Or would it be automated? Perhaps conditioned on whether the last build succeeded or not?

[BenjamenMeyer]

With GitHub Actions we could automate it.

[stephengtuggy]

Sounds good.

[BenjamenMeyer]

we've done enough for 0.7.x with the migration from Travis-CI to GH Actions. More work can be on 0.9.x

[stephengtuggy]

Hmm. I have some concerns about this approach. We might be able to automate a weekly alpha release. As far as beta releases go, though, it seems to me that we still need humans to be in charge of kicking off the process. At least for now.

We human devs are the only ones who really know when the code is ready to release a beta build. And it depends on a lot of factors, not all of which can be explained easily to an automated algorithm.

Am I making sense? @vegastrike/code-developers can we get some others to weigh in on this?

Thanks!

[Loki1950]

Making a lot of sense @stephengtuggy besides we are not changing the code or assets that fast to justify the automation.

[BenjamenMeyer]

@stephengtuggy so for automating releases I'd probably still do betas too but it'd have to be setup something like:

• version values (major/minor) are human modified
• release status (alpha/beta/final) are human modified
• patch release is auto-generated using a date value This way when we move from an alpha to a beta release the machinery can still work, but it'd move to the beta release. Final releases would not be automated at all so once something hits the final release stage then the machinery would ignore it and humans would have to get involved to do any more releases on the branch.

This is only a machinism to help get changes into the early releases faster (e.g the release early, release often mantra of open source) so that people can confirm bug fixes, enhancements, etc as we go and hopefully we catch issues faster. This also assumes we have a large enough group testing it to make it work too - which as we get things back in shape and start making more releases will hopefully grow as well.

I don't want to just start dumping releases into GitHub without people actually making use of them as that would just overwhelm those looking to pick it up, and also add storage to GitHub that we might not need. So whatever happens here needs to be driven at a level that is useful to the VS community and can be advanced to GitHub as being so as well.