Notes on maintaining the Neovim project.
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)
The forecasting problem might be solved with an explicit priority system (like
Bram’s todo.txt). Meanwhile the Neovim priority system is defined by:
+planlabel increases the ticket’s priority merely
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
Release “often”, but not “early”.
master branch is the “early” channel; it should not be
released if it’s not stable. High-risk changes may be merged to
the next release is not imminent.
For maintenance releases, create a
release-x.y branch. If the current release
has a major bug: