На самом деле не так важно, идёт ли речь о библиотеке или о крупном приложении. Схема семантического версионирования (например, semver) отлично подходит и для больших приложений. Её можно применять даже к набору приложений, объединённых в платформу, хотя в этом случае возникают серьёзные сложности.
Главный вопрос: планируете ли вы внедрять поддерживаемое устаревание функций в одном релизе, а их полное удаление — только в следующем мажорном? Наличие устаревших, но поддерживаемых функций требует значительных усилий. При изменениях в модели сохраняемых данных устаревание часто становится невозможным. В таком случае нельзя даже выпустить минорную версию с устаревшими функциями — приходится сразу переходить к следующей мажорной версии. Именно здесь крупные приложения обычно сталкиваются с проблемами: вы переходите от 3.0.0 к 3.0.1, а затем к 4.0.0, потому что не можете обеспечить обратную совместимость. Если у вас часто происходят breaking changes, соблюдение semver приносит мало пользы.
Тем не менее, я гораздо больше предпочитаю именно такой подход, поскольку он чётче сообщает разработчикам о предстоящих breaking changes. Схема YYYY.N ничего не говорит ни разработчику, ни администратору.
Итак, вопрос в том, что именно вы хотите донести через версию? Если вы планируете шесть релизов с новыми функциями (которые могут быть, а могут и не быть breaking), и каждый шестой релиз будет получать более длительную поддержку с патчами, при этом вы не хотите версионировать патч-релизы, то схема X.Y подойдёт, где Y=0 обозначает релиз с длительной поддержкой. X — просто число. Проблема возникает, когда X — это год: тогда Y быстро начинает ассоциироваться с месяцем. Значит, новые релизы с длительной поддержкой будут выходить в январе? Мне всегда приходится проверять, какая версия Ubuntu является LTS, и это меня раздражает.
А что если Discourse просто продолжит использовать текущую мажорную версию? Следующий релиз с длительной поддержкой будет называться 4.0; затем выйдут 4.1–4.5 как релизы с новыми функциями; после этого — 5.0, который станет новейшим релизом с длительной поддержкой.
Также исчезнет неловкая ситуация, когда релиз откладывается из-за серьёзной проблемы.
При желании можно добавить номер «патча», если вы планируете явно выпускать патчи (вместо непрерывных обновлений). «Но тогда получится x.y.z, что и есть semver». Нет, это лишь выглядит как semver, но им не является. Каждый новый «минорный» релиз может содержать breaking changes. Поэтому я предлагаю просто придерживаться схемы X.Y, где Y=0 означает LTS.
Отдельно от строки версии: мне нравится новый план релизов.
