Столкновение с SemVer: Как выпустить исправление ошибки в последней стабильной версии, если есть какие-то альфа / бета / r c версии и работа продолжается?

Question

Я поддерживаю некоторые js библиотеки . Релизы следуют за SemVer. Текущая стабильная версия - 1.5.0 . Я работаю над 1.5.1 и имею 1.5.1-beta.2 , который публикуется в npm с тегом "next". Сегодня я получил сообщение об ошибке, обнаружил проблему и готов ее исправить. Дело в том, что 1.5.1 не будет завершено в ближайшие дни, все оказалось сложнее, чем я планировал изначально. Но я хочу, чтобы исправление было опубликовано.

Какова правильная стратегия в этой ситуации? Очевидный подход, которого я хотел бы избежать, это отложить исправление ошибки до тех пор, пока 1.5.1 не будет сделано и опубликовано, а затем выпустить 1.5.2 , содержащее исправление.

Другой способ - опубликовать sh исправление как 1.5.1 на основе 1.5.0 , а затем продолжить предыдущую работу, переключив его с 1.5.1-beta.2 до 1.5.2 или даже 1.6.0 . Я обеспокоен несоответствием цепочки результатов в этом случае:

1.5.0 → 1.5.1-бета → 1.5.1-бета.1 → 1.5.1-бета.2 → 1.5.1 ( исправление ошибки на основе 1.5.0) → 1.5.2 (на основе 1.5.1-бета.2)

Как такие коллизии решаются с помощью SemVer?

Answer 1

Итак, у вас есть набор ошибок A, в настоящее время выпекаемый как 1.5.1-бета2, и у вас есть новый набор ошибок B, для которого вы хотите немедленно получить исправление. Правильным механизмом для этого является разветвление 1.5.0, исправление набора ошибок B и выпуск 1.5.2 (при условии, что вам не нужна бета-версия). Затем объедините исправления B с рабочей веткой A, выпустите 1.5.3-beta1 и перейдите к официальному выпуску.

Это становится немного сложнее, когда у вас запущены две параллельные бета-последовательности, особенно когда Вы не уверены, что из этого выйдет первым, но это управляемо. Главное - просто помнить, как приоритет SemVer влияет на решения, принимаемые вашими клиентами (применяемые ими алгоритмы), будь то быстрое отслеживание конкретной версии в их производственных системах, а также то, как их разработчики извлекают у вас уроки.

Мои производственные системы имеют два входа:

1. Разработка - это продукт моих инженеров.
2. Автоматизированное обслуживание - это продукт системы, которая:
   • Извлекает выпуски исправлений и применяет их к развилке моего текущего производственного кода.
   • Тестирует примененные изменения на основе обширного набора функциональных и эксплуатационных тестов.
   • Если тесты зеленого цвета, то летные тесты изменения в моей производственной среде, в то же время отслеживая необычные изменения частоты отказов производства.
   • Пока все идет хорошо, и человек не вмешивается, чтобы остановить его, в конечном итоге выкатывает изменения в Вся производственная система.

Есть, конечно, вариации s для услуг и упакованных продуктов. Дело в том, что вы можете использовать свои точки выпуска, чтобы сигнализировать вашим клиентам или разработчикам о том, что у вас есть важное исправление ошибки, которое имеет небольшой риск поломки. Не существует требования, чтобы 1.5.2 имела какое-либо происхождение от 1.5.1-бета #. Вы не обязаны когда-либо выпускать 1.5.1. Однако в примечаниях к выпуску обычно добавляется комментарий о том, что 1.5.2 является исправлением для ошибки в 1.5.0 и не содержит исправлений в 1.5.1-бета #.

Хотя вы, возможно, никогда не столкнетесь с необходимостью, вам не нужно включать исправления ошибок из 1.5.2 в ваш возможный выпуск 1.5.3, при условии, что более поздний выпуск пройдет контроль качества. Иногда бывает так, что указанное c исправление ошибки оказывается неприменимым в более поздних выпусках.

Как вы поддерживаете качество вашей продукции, полностью зависит от вас. То, как вы сигнализируете об уровне риска / важности для конкретной версии c, определяется стандартом SemVer .