* DOCS Update "release numbering" to document the fact that lock step releases are not required
[ci skip]
* DOCS Update "making a SilverStripe core release" to clarify recipe versus module without lock step
Also adds note about peer reviewing the plan before release
[ci skip]
We're adopting CVSS (https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator),
which allows us to classify the impact of security issues
based on industry standard metrics.
While there is still a lot of room for interpretation,
it is more objective than our previous system of "critical/high/medium/low",
with one sentence descriptions on how we interpret that "severity rating".
This effectively changes our process to only apply
security fixes to release lines in "limited support" (currently 3.6 and 3.7)
if they're considered "critical" (CVSS > 9.0).
We've already limited preannounces to CVSS >7.0 in these docs.
Moved the guts to "making a core release", since it's only really relevant to that audience.
There's more work to do around making security and non-security releases the same (less special handling),
but I think this is a good start.
[ci-skip]
- Stronger wording around "use composer"
- Consistent domain and email address naming
- Removed example for publishing non-composer modules (those shouldn't be encouraged)
- Removed instructions for installing modules from archives
[ci skip]
We have too many docs to list these out now,
even in 3.x this was a bit of a stopgap solution.
Point to a centrally managed URL on silverstripe.org
instead, where we can update the list of "core modules" regularly
without breaking URLs in the docs etc
Note that these URLs are also used internally by the
Open Sourcerers team.
JIRA isn't fully under the OSS team's control,
and played up in the past (Dan couldn't move issues).
Since Github has project boards now, and we're paying
for private repos on github.com/silverstripe-security already anyway,
there's no reason to introduce another tool (JIRA) into our workflows.
No need to move existing issues, the JIRA board hasn't been used in a while.
Which leads to unclear ownership and status of security issues,
and is exactly the reason for this change ;)
The role moves around based on current availability.
@tractorcow has done most of the last releases,
but a separate team (headed by @dhensby) will be
responsible for 3.x releases.
There's not really much point to declaring a release maintainer,
unless there's disagreements in the core team where we need
an arbitrator. So far those conflicts have been resolved
on individual tickets (e.g. what should go into a release),
and the process for that seems to work well.
It was getting a bit lost halfway down the contributing/code instructions,
in between the detailed git instructions.
Also reordered the docs TOC for that folder by renaming the files.
