c70c8b607f
- Lua - developer guidelines - MAINTAIN.md - TUI: cleanup - TUI: mention Windows terminfo builtins - cleanup if_pyth, redirect python-bindeval tag Helped-by: Björn Linse <bjorn.linse@gmail.com> Helped-by: erw7 <erw7.github@gmail.com>
1.8 KiB
Maintaining the Neovim project
Notes on maintaining the Neovim project.
See also: https://github.com/git/git/blob/master/Documentation/howto/maintain-git.txt
General guidelines
- Decide by cost-benefit
- Write down what was decided
- Constraints are good
- Use automation to solve problems
- Never break the API
Ticket Triage
In practice we haven't found a meaningful way to forecast more precisely than "next" and "after next". That means there are usually one or two (at most) planned milestones:
- Next bugfix-release (1.0.x)
- Next feature-release (1.x.0)
The forecasting problem might be solved with an explicit priority system (like Bram's todo.txt). Meanwhile the Neovim priority system is defined by:
- PRs nearing completion (RDY).
- Issue labels. E.g. the
+planlabel increases the ticket's priority merely for having a plan written down: it is closer to completion than tickets without a plan. - Comment activity or new information.
Anything that isn't in the next milestone, and doesn't have a RDY PR ... is just not something you care very much about, by construction. Post-release you can review open issues, but chances are your next milestone is already getting full :)
Release Policy
Release "often", but not "early".
The (unreleased) master branch is the "early" channel; it should not be
released if it's not stable. Medium-risk changes may be merged to master if
the next feature-release is not imminent.
For maintenance releases, create a release-x.y branch. If the current stable
release has a major bug:
- Fix the bug on
master. - Cherry-pick the fix to
release-x.y. - Cut a release from
release-x.y(runscripts/release.sh).