Notes on maintaining the Neovim project.
See also: https://github.com/git/git/blob/master/Documentation/howto/maintain-git.txt
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:
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 :)
The goal is "early and often".
Up to now we use only one branch, the master
branch.
master
is unstable we don't release.master
.master
.master
.This is a bit silly, but it works ok. And it keeps master
from biting off
more feature-creep than it can chew.