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) planned milestones:
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 for having a plan written down: it is closer to completion than tickets without a plan.
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 “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: