Как вы оцениваете эффективность политики обновления библиотеки?

Политика обновления библиотеки, которую вы описываете, выглядит хорошо продуманной и имеет свои плюсы и минусы. Давайте рассмотрим их подробнее:

### Плюсы:

1. **Поэтапный подход к выпуску**: Выпуск минорной версии в статусе pre-release позволяет вам тестировать новую функциональность и фиксировать ошибки до того, как она станет доступной для широкой аудитории. Это снижает риск выпуска нестабильного кода.

2. **Гибкость обновлений**: Постепенное добавление патчей позволяет вам реагировать на отзывы пользователей и быстро исправлять ошибки, что улучшает качество кода.

3. **Поддержка консервативных пользователей**: Оставление предыдущей минорной версии доступной для пользователей, предпочитающих более стабильные версии, демонстрирует уважение к различным требованиям пользователей.

4. **Упрощение управления зависимостями**: Упаковка новых функций в минорные версии и фиксация ошибок в патчах позволяет пользователям выбирать, когда и как они хотят обновляться.

### Минусы:

1. **Потенциальная путаница с версиями**: Если у вас много минорных и патч-версий, пользователи могут запутаться в выборе правильной версии, особенно если они не знакомы с вашей системой нумерации версий.

2. **Зависимость от качества тестирования**: Хотя использование pre-release версий даёт возможность тестировать новые функции, это также накладывает ответственность за качество тестирования. Если тесты не полные, пользователи могут столкнуться с проблемами даже в стабильной версии.

3. **Задержки с выпуском стабильных версий**: Постоянное добавление патчей может привести к задержкам в выпуске стабильной версии, что может быть неприятно для пользователей, ожидающих новых возможностей.

4. **Управление yank-версиями**: Удаление (yank) unstable версий может вызвать недоумение у пользователей, если у них уже установлены эти версии. Они могут потерять доступ к использованию этих версий, если они не знали о изменениях.

### Рекомендации:

- **Документация**: Обязательно предоставляйте ясную и подробную документацию о вашей политике версионирования и обновлений. Это поможет пользователям лучше понять логику и структуру версий.

- **Коммуникация**: Регулярно общайтесь с пользователями о предстоящих изменениях, новых функциях и патчах, чтобы они были в курсе этих событий.

- **Автоматизация тестирования**: Инвестируйте в хорошую систему автоматического тестирования, чтобы минимизировать возможные баги в новых версиях.

В целом, ваша политика обработки обновлений может быть эффективной, если правильно управлять коммуникацией и тестированием.

Постепенно я дополняю её патчами.
 
 Непонятно какую схему вы планируете для разных 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-я бета, а до неё ещё несколько альф было, поглядим сколько ещё багов нам заведут»