Skip to content

Commit 337dbf5

Browse files
committed
move maintainers guide
1 parent 0f6814c commit 337dbf5

File tree

2 files changed

+47
-47
lines changed

2 files changed

+47
-47
lines changed

MAINTAINERS_GUIDE.md

+47
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,47 @@
1+
Maintainer's Guide
2+
==================
3+
4+
5+
Commit Policy
6+
-------------
7+
8+
* Pull requests from outside contributors require a review from a maintainer.
9+
10+
* Maintainers should avoid working on a main branch directly and create branches for everything. A code review from another maintainer is recommended but not required, use your best judgment.
11+
12+
13+
14+
Release process
15+
---------------
16+
17+
Releases (minor) typically happen on a 6-week schedule.
18+
19+
For major/minor releases you'll be releasing from `main` For patch releases you'll be releasing from a stable branch, such as `11-stable`. This allows ongoing development of new features to continue in isolation (in main) without those changes leaking into patch releases (which should focus only on fixing breaking changes).
20+
21+
The goal being that minor version series always get more stable over time and that patch releases do not add features.
22+
23+
* For patch releases: First switch to the associated stable branch (i.e., `11-stable`)
24+
25+
* Update `CHANGES.md` with everything interesting since the last update.
26+
27+
* Update version numbers using the three-part x.y.z notation everywhere:
28+
29+
* The header in `CHANGES.md` (this is where the site looks for the latest version number)
30+
* `version` attribute in `package.json`
31+
* `version` attribute in `package-lock.json` (run `npm install`)
32+
* `release` variable in `docs/conf.py`
33+
* All mentions of version number in the `README.md`
34+
* Update `SECURITY.md` version table
35+
36+
* Commit the version changes and tag the commit with the version number (`10.4.0`, no "v" prefix or anything like that)
37+
38+
* For major/minor releases: Create (or push push) the `[major]-stable` branch such as `11-stable`
39+
40+
IE, the `11-stable` branch should always point to the latest stable release in the 11 series.
41+
42+
* Push the commit the tag (`git push && git push 10.4.0`)
43+
44+
45+
Pushing the tag triggers the update process which can be monitored at http://highlightjs.org/api/release/
46+
47+
When something didn't work *and* it's fixable in code (version numbers mismatch, last minute patches, etc), simply make another release incrementing the third (revision) part of the version number.

maintainers-guide.rst

-47
This file was deleted.

0 commit comments

Comments
 (0)