RFC: Новая стратегия версионирования для Discourse

Это обсуждение выглядит не очень хорошо. Я вижу, что команда разработки приняла решение перейти на новую систему версионирования, которая имеет смысл для них, в то время как другие внезапно начали считать, что версия Discourse следовала семантическому версионированию… чего не было. Это всегда была rolling-версия, по крайней мере, начиная с версии 1.0, или нет?

Но аргументы всех сторон в споре кажутся несостоятельными:

  • «индустриальный стандарт»: Linux использует чётные главные версии для стабильных выпусков и нечётные для разработки.
  • «земля вращается вокруг Солнца»: ну, если вы примете ислам, то попадёте в неприятности, потому что версии будут пропущены, и они больше не будут соответствовать оборотам Солнца, а будут синхронизированы с циклами Луны. Здесь вы теперь понимаете, что, выбрав схему версионирования YYYY.Y.Z вместо X.Y.Z, вы навязали доминирующую культуру.
  • Минорные выпуски остаются неясными: вы упоминаете «предполагая месячный ритм», но это может быть также 3 недели или 7 дней, в зависимости от функциональности. В таком случае имеет смысл вести отсчёт Y с нуля, или же вы действительно планируете выпускать версии раз в месяц, в этом случае отсчёт M с единицы был бы более логичным?

Главное изменение, которое я вижу, заключается в том, что, приняв месячный ритм, команда Discourse формирует ожидания и отказывается от целевых дат выпуска в пользу регулярных релизов.

LTS на 8 месяцев не звучит особенно «долгосрочно». NodeJS развивается слишком быстро, но они поддерживают LTS в течение 30 месяцев и одновременно несколько текущих версий, а Ubuntu сохраняет LTS на протяжении лет. Хотя я понимаю, что Discourse ни язык программирования, ни операционная система, это кажется сигналом о том, что новый функционал будет выпускаться довольно быстро, что поднимает ещё один вопрос: поскольку новые настройки администратора появляются время от времени, мы скоро попадём в ад WordPress с бесконечными опциями и непостижимой сложностью администрирования сайта, иначе говоря, в раздутый софт. Тогда становится важным прояснить, как перейти от существующих релизов с целевыми датами к регулярным выпускам и как выбирать, какие цели отбрасывать (или откладывать) для конкретного релиза и т. д. (возможно, это уже задокументировано, но я это пропустил.)

Не могли бы вы поделиться своими соображениями относительно темпа разработки и системы версионирования, а также тем, что вы планируете сделать, чтобы администраторы не утонули в избытке настроек и не столкнулись с повышенным порогом обучения?

:heart: :discourse: