Сопровождение проекта Neovim

Примечания по сопровождению проекта Neovim.

Общие рекомендации:

• принимать решения на основе анализа затрат и выгод;
• документировать принятые решения;
• ограничения полезны;
• использовать автоматизацию для решения проблем;
• никогда не нарушать работу API.

Сортировка заявок: На практике мы не нашли более точного способа прогнозирования, чем «следующий» и «после следующего». Это означает, что обычно есть один или два (максимум) запланированных этапа:

• следующий выпуск с исправлением ошибок (1.0.x);
• следующий релиз с новой функцией (1.x.0).

Проблему прогнозирования можно решить с помощью явной системы приоритетов (например, todo.txt Брэма). Тем временем система приоритетов Neovim определяется следующим образом:

• PR-запросы, близкие к завершению (RDY);
• метки задач. Например, метка +plan увеличивает приоритет заявки только за счёт того, что план записан: она ближе к завершению, чем заявки без плана;
• активность комментариев или новая информация.

Всё, что не входит в следующий этап и не имеет RDY PR... вас это просто не очень волнует, по определению. После выпуска вы можете просмотреть открытые вопросы, но, скорее всего, ваш следующий этап уже будет полным :)

Политика выпуска: Выпускайте «часто», но не «рано».

(Невыпущенная) ветка master — это «ранний» канал; её не следует выпускать, если она нестабильна. Изменения с высоким риском могут быть объединены с master, если следующий выпуск не неизбежен.

Для выпусков обслуживания создайте ветку release-x.y. Если текущий выпуск содержит серьёзную ошибку:

1. Исправьте ошибку в master.
2. Перенесите исправление в release-x.y.
3. Создайте выпуск из release-x.y.
   • Запустите ./scripts/release.sh.
   • Обновите (принудительно отправьте) удалённый тег stable.
   • Ночная задача (https://github.com/neovim/bot-ci/blob/master/ci/nightly.sh) обновит ресурсы выпуска на основе тега stable.

Смотрите также:

• https://github.com/neovim/neovim/issues/862;
• https://github.com/git/git/blob/master/Documentation/howto/maintain-git.txt.