Eugene-Usachev
@Eugene-Usachev

Насколько хороша такая политика обновления библиотеки?

Политика заключается в следующем: сначала я выпускаю новую минорную версию в формате "major.new_minor.patch-unstable". Её я устанавливаю в pre-release. Постепенно я дополняю её патчами. Когда я уверен, что версия не содержит багов, я меняю её на стабильную "major.new_minor.patch". После этого я yank все unstable версии и предпредыдущую минорную версию (оставляя предыдущую минорную версию для более консервативных людей).
  • Вопрос задан
  • 181 просмотр
Решения вопроса 1
Постепенно я дополняю её патчами.

Непонятно какую схему вы планируете для разных unstable-версий. major.new_minor.patch-unstable.1, major.new_minor.patch-unstable.2. Кстати, рекомендую выбрать какой-то более привычный prerelease-идентификатор вместо unstable, например alpha и beta.

Также рекомендую подглядеть схему версионирования у какого-нибудь популярного крейта, например actix-web. Они используют предрелизные версии перед мажорными релизами.

Тут кстати встаёт вопрос, а так ли вам нужны предрелизы для ПАТЧ-версий библиотеки? Выглядит как чрезмерно детальное версионирование. Обычно когда публикуется патч-апдейт, и в нём обнаруживается баг, то просто выпускается новая версия с фиксом и со следующим patch-числом (т.е. была 2.5.2, потом вышла 2.5.3 с багом, для фикса которого выпустили 2.5.4).

Возможно я неправильно вас понял, и вы предполагали использовать предрелизы для новых минорных и мажорных версий - тогда это более разумное решение.

Собственно предрелизы на то и меньше релизов при операциях сравнения, что для этого и придуманы. Т.е. например:
1.2.5 < 1.3.0-alpha.1 < 1.3.0-alpha.2 < 1.3.0-beta.1 < 1.3.0

Чтобы пользоваться предрелизами правильно и потом не кусать локти из-за неудачно выбранной схемы, почитайте внимательно правила сравнения в спеке semver для предрелизов и подсмотрите в популярные пакеты как кто делает. Лично мы используем схему c alpha/beta плюс через точку номер предрелизного билда.

Схема именования предрелизов должна быть устроена так, чтобы решать задачу "приближения" к релизной версии. Если обычные 3.5.7 нужно читать как "3-я версия API + 5-й набор фичей для этого API + 7-я версия патчей для этого набора фичей", то 4.0.0-beta.6 нужно читать как «вроде бы уже почти 4.0.0, но ещё непонятно сколько ещё косяков надо перепрыгнуть, чтобы добраться до 4.0.0. На глаз вроде бы уже немного осталось (beta), но это уже 6-я бета, а до неё ещё несколько альф было, поглядим сколько ещё багов нам заведут»
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы