При текущих инструментах запуска и новой структуре веток вы можете контролировать время обновления, действуя примерно так:
- Релиз v2026.02
- Вы указываете
version: release/v2026.02в файле app.yml - Релиз v2026.03
- Вы запускаете пересборку. Вы всё ещё получаете версию 2026.02, но с последними исправлениями безопасности
- Когда будете готовы, переключитесь на
version: release/v2026.03в app.yml
Однако ручное редактирование файла app.yml каждый месяц — это далеко не идеальный вариант, поэтому мы надеемся разработать систему, которая сделает процесс более удобным для пользователя.
Процесс, описанный в оригинальном посте, позволяет нам рассматривать ветки как «кандидаты в релизы» перед тем, как официально объявлять их релизами. Пока точно неясно, как именно мы будем использовать эту возможность — думаю, это будет определяться по мере того, как мы привыкнем к новой системе.
Мы пытаемся найти баланс между скоростью разработки Discourse и стабильностью для пользователей с обширными кастомизациями. Задержка в 3+ месяца перед тем, как новые функции попадут к нашим клиентам, недопустима. Более того, для нас ежемесячные релизы даже кажутся медленными. В настоящее время мы по-прежнему планируем использовать ветку latest для большинства наших хостинг-решений.
Но, конечно, для тех, кто самостоятельно размещает Discourse, я понимаю желание иметь менее частые изменения. Именно здесь и приходят на помощь ESR-релизы.