Versioning / Release Process

[jtauber]

• in 0.X, we do not make an alpha / beta / release-candidate distinction
• effectively, all 0.X releases are alpha or beta
• planned releases are given a 0.X.0 version
• hot-fix releases to a 0.X (while we're working towards a different planned release) are given a version 0.X.Y (Y > 0)
• we will do alpha / beta / release candidates for 1.0 and beyond

So, for example:

We have released 0.3.0 and are currently working on 0.4.0. If we notice a mistake in 0.3.0 that is holding up implementation testing and we don't want to wait for 0.4.0 to fix it, we can release 0.3.1 with just the fix added to 0.3.0.

If there is more work to do after 0.4.0 prior to declaring 1.0.0, we will work on a 0.5.0. When our 0.X.Y release is a candidate for 1.0.0 (by consensus of working group), we will release it as 1.0.0-rc1.

Prior to 1.0.0-rc1, I'm not sure if there needs to be a review process before release. All post-1.0 releases that aren't alpha or beta should go through a release candidate, however.

I'm inclined to suggest that, post 1.0:

• alphas and betas can be done unilaterally by the release manager
• all release candidates for hot-fixes can be done unilaterally by the release manager but the actual release requires a review period and WG consensus
• all release candidates for normal (.0 / non-hotfix) releases require WG consensus

So for example, the release manager (me for now) could unilaterally release:

• 0.4.0
• 0.4.1
• 1.0.1-rc1
• 1.1.0-alpha1
• 1.1.0-beta1

But WG consensus is required for:

• 1.0.0-rc1
• 1.0.0
• 1.0.1
• 1.1.0-rc1
• 1.1.0

[jag3773]

I'm in favor!

[jag3773]

Briefly describe branching process.

[jag3773]

Update https://docs.burrito.bible/en/latest/schema_docs/design.html#versioning when we're ready.

[jtauber]

Done on design-doc-updates branch. See #258 for status.