From fbb8a789f605a304e53b79e96b700b7f154aafcd Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Thu, 25 May 2023 09:35:38 -0600 Subject: [PATCH] Add release checklist issue template; Document some of our timelines around releases (#1538) * 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 --- .github/ISSUE_TEMPLATE/release.md | 34 ++++++++++++++ .../internal/newsfragments/1538.clarification | 1 + meta/releasing.md | 45 +++++++++++++++++++ 3 files changed, 80 insertions(+) create mode 100644 .github/ISSUE_TEMPLATE/release.md create mode 100644 changelogs/internal/newsfragments/1538.clarification diff --git a/.github/ISSUE_TEMPLATE/release.md b/.github/ISSUE_TEMPLATE/release.md new file mode 100644 index 00000000..83701f14 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/release.md @@ -0,0 +1,34 @@ +--- +name: [SCT] Release checklist +about: Used by the Spec Core Team to create a new release. +title: 'Matrix 1.X' +labels: 'release-blocker' +assignees: '' + +--- + + + + + +Date: **Thursday, May 25, 2023** +Previous release: + +Preflight checklist ([release steps](https://github.com/matrix-org/matrix-spec/blob/main/meta/releasing.md)): + +* [ ] Blog post written +* [ ] Check for release blockers that may have been missed +* [ ] Review/fix the changelog + +Release checklist ([release steps](https://github.com/matrix-org/matrix-spec/blob/main/meta/releasing.md)): +* [ ] Branch stuffs +* [ ] Github release artifact +* [ ] Published to spec.matrix.org +* [ ] All links work +* [ ] Publish blog post +* [ ] Announce in #matrix-spec, client developers, HS developers, SCT office, and other rooms as warranted +* [ ] Post to Twitter/Mastodon +* [ ] Close this issue + +Known release blockers: +* [ ] diff --git a/changelogs/internal/newsfragments/1538.clarification b/changelogs/internal/newsfragments/1538.clarification new file mode 100644 index 00000000..3362118d --- /dev/null +++ b/changelogs/internal/newsfragments/1538.clarification @@ -0,0 +1 @@ +Document more of the spec release timeline/process. \ No newline at end of file diff --git a/meta/releasing.md b/meta/releasing.md index 7483c357..92dd9be8 100644 --- a/meta/releasing.md +++ b/meta/releasing.md @@ -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