wholetrans/docs-matrix-spec
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Add release checklist issue template; Document some of our timelines around releases (#1538)

Browse source 
* Add a spec release checklist issue template

because I'm tired of copy/paste

* Document a chunk of our release approach

This should probably go elsewhere, but here is fine for now as a SCT-referenced doc/content.

* changelog

* Brief clarifications
This commit is contained in:
Travis Ralston 2023-05-25 09:35:38 -06:00 • committed by GitHub
parent 089d209047
commit fbb8a789f6
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
3 changed files with 80 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

45
meta/releasing.md
View file

@ -4,6 +4,51 @@ The whole specification is now released as a single unit/artifact. This document
the process for releasing the specification and a description of how the (public)
machinery works.
## Timeline
The spec is released each calendar quarter. The target release dates are within the
following ranges:
* Q1: January 20-27 (critically, before FOSDEM).
* Q2: May 20-27.
* Q3: August 20-27.
* Q4: November 1-15 (before recurring November conflicts, like IETF).
The SCT aims to have dates picked out by:
* Q1: January 10.
* Q2: May 1.
* Q3: August 1.
* Q4: October 15.
When a release date is picked, a [checklist](https://github.com/matrix-org/matrix-spec/issues/new?assignees=&labels=release-blocker&projects=&template=release.md&title=Matrix+1.X)
issue is created to track details of the release. Release blockers should continue to
be accepted up until 7 calendar days prior to the release date.
**Release dates are not promises.** The SCT reserves the ability to change, cancel,
postpone, etc a release for any reason. Do not rely on a release happening on a given
day until the release has actually happened & blog post published.
Once a release is scheduled, the SCT will begin planning what the next release is
expected to look like. The plan should be included in the spec release blog post,
and be ready for exeuction on spec release day. Plans are guides and not promises.
A blog post for the SCT members to review should be ready at minimum 1 week before
the target release date. 1-2 days before the release itself, the prerequisite steps
below are executed to ensure the spec release can go ahead.
## Release composition
*This section is a work in progress.*
Mentioned above, the SCT aims to have spec releases quarterly. Each quarter has a
slightly different theme to it:
* Q1: Massive feature release, if possible. This generally happens thanks to FOSDEM.
* Q2: Regular feature release, if possible.
* Q3: Momentum-continuing feature release, if possible.
* Q4: Preferably a maintenance release, but will accept features per normal.
## Prerequisites / preparation
First, can we even release the spec? This stage is mostly preparation work needed