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:
+plan
label 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".
The (unreleased) master
branch is the "early" channel; it should not be
released if it's not stable. High-risk changes may be merged to master
if
the next release is not imminent.
For maintenance releases, create a release-x.y
branch. If the current release
has a major bug:
master
.release-x.y
.release-x.y
.
./scripts/release.sh
stable
tag.stable
tag.此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。