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