Когда достигнута стабильность
Один раз: когда разработка закончена

Суть одно и то же.

Ирония понятна, но различие всё же есть: «когда достигнута стабильность» работы программы (в сравнении с ее работой в другие моменты разработки — возможно субъективно, а возможно и объективно по каким-либо параметрам), а не стабильность (отсутствие) разработки.

стабильность (отсутствие) разработки

Толсто. Когда заканчивается разработка текущего релиза, начинается его поддержка.

роллинг, до того как в очередной раз всё сломали и после того как уже починили

мажорные версии сменять не по принципу хрома, а при значительной переработке кода/поведения/совместимости, для хрома подходит дата и номер билда.

Другой вариант: когда реализована запланированная на релиз функциональность.

Роллинг для дэсктопных программ, роллинг для домашнего дэсктопа, стабильные выпуски для проdакshен серверов, стабильные для серверных программ.

Для дистрибутивов — когда угодно или rolling release, тут еще можно что-то обсуждать.

Для SaaS — разумеется, rolling release.

Для программ/библиотек — разумеется, semantic versioning.

Очень странный опрос.

ЯННП. У каждого подхода есть плюсы и минусы. Без контекста применения опрос бесмысленный.

программы: Сразу после очередного этапа активной разработки.

дистрибутивы: Никогда: только rolling release.

Штабильность

Правильного ответа нет

Потому что для программ и дистрибутивов должна быть разная политика.

В любом случае, наличие установленной политики лучше чем её отсутствие.

где вариант «когда голоса в голове подскажут»?

rock & roll
Никогда нельзя заранее быть уверенным, что «достигнута стабильность». Даже тесты, эффективный менеджер-тимлид и красивые сертификаты не помогут. Вопрос только в том, насколько нестабилен тот или иной релиз.

Rolling release для версий с обратной совместимостью. (но версионирование для себя оставлять, в формате <поломка обратной совместимости>.<новые фичи доступны>.<багфикс>)

Новая версия - при поломке обратной совместимости.

Присоединяюсь.

Кто-нибудь может дать расшифровку этих каракуль?

Один раз: когда разработка закончена

a как же CI/CD?

Отметил «Когда достигнута стабильность», но опрос какой-то странный. Лучше заранее планировать цикл разработки, например, 2 месяца все ломать, 3 месяца чинить, месяц или 2 тестировать и потом выпускать новую версию. Так что и «Когда достигнута стабильность», и «С регулярными интервалами», и «Непосредственно перед активным продолжением разработки». А для дистрибутивов rolling-release.

Ответил «Сразу после очередного этапа активной разработки», но тогда вопрос, что это за этапы. Думаю, у вменяемой программы должен быть roadmap: вот сделаем то-то и то-то, выпустим 0.2, это и это - 0.3, а вот как весь список исчерпаем - получайте 1.0, а мы начинаем следующий список составлять.

Это что касается программ. С дистрибутивами вариантов больше, наверное, самый универсальный - «когда достигнута стабильность», но выбрать разные варианты опрос не позволяет.

Gentoo. Вечно молодой.

Как Gentoo, один раз в 5 лет или того реже.

Никогда: только rolling release.

Надо ещё понимать, что альфа версия софта бывает написана прямыми руками и в версии альфа прекрасно работает и не глючит, а бывает что софт изначально написан кривыми руками и к стабильной версии тянет за собой шлейф глюков и багов, которые почему-то не пофиксены. Не во всех бинарных дистрах это понимают, поэтому тухлые версии софта некоторых программ предлагаются по умолчанию, когда эти программы сами по себе не глючные были всегда.

Кстати, хороший детектор качества софта — это посмотреть на альфу версию.

роллинг на дексктопе, достигнута стабильность на серваках

Сразу после очередного этапа активной разработки

Примерно так. Запланировать список изменений, сделать, зарелизить. Чем короче список, тем лучше. Релизы чаще, меньше сюрпризов в каждом. В идеале изменения мелкие и по одному закидываются в транк, получается rolling release.

Что для дистрибутивов, что для программ выпуск новой версии должен быть связан со стабильностью работы всех нововведений. Какой смысл выпускать новые версии по расписанию, когда качественная работа всех компонентов не обеспечена?

какой-то виндузовый опрос
или ТС неизвестно что такое опенсорс?

В декабре, я решил проверить недавно добавленную на Twitter поддержку опросов, и вывел туда (своим follower'ам) опрос «When to release new versions of software (if at all)?» с четырьмя вариантами ответа (больше там нельзя). Результаты меня удивили — вариант «At regular intervals» набрал 45% (и несколько мейнтейнеров разных проектов высказались в своих твитах в его поддержку). Вот и решил проверить на LOR. ;-) Здесь вариант «С регулярными интервалами» пока что набирает лишь 8% (33 из 390). Понятно, что опросы разные — у этого общего варианта были другие конкурирующие с ним варианты ответа — и всё же столь значительное отличие удивляет (или/и подтверждает, что мне было чему удивиться в результатах с Twitter). Возможно, среди принявших участие в опросах на Twitter и LOR сильно разный процент мейнтейнеров проектов? Возможно, на LOR сильно влияет возможность подглядеть текущие результаты голосования до его «завершения», после чего будущие участники голосования либо присоединяются к большинству, либо с ним «спорят», а не думают непредвзято? Другими словами, на LOR могут сильно влиять первые несколько голосов. (С другой стороны, на Twitter аналогично могут влиять твиты с высказыванием своего мнения, которые были как раз в пользу этого варианта.)

Полностью результаты с Twitter:

Just before breakage - 11%
Right after breakage - 3%
Both: stable & devel - 41%
At regular intervals - 45%

Варианты ответов давались именно в таком порядке. Голосование длилось 24 часа, во время голосования текущие результаты становились видны лишь уже проголосовавшим. Набралось 116 голосов.

Тут есть несколько моментов. С точки зрения пользователя и девелопера это «Когда достигнута стабильность» и «Один раз: когда разработка закончена». В первом случае по моему мнению это «хоть не все, но работает стабильно» во втором «все и стабильно», конечно предпочтительнее второй вариант. Причины понятны, пользователю нужно работать, а не бороться с глюками или искать обходные пути для реализации еще не работающий функций, девелоперу горааздо меньше гемороя с поддержкой. А вот все промежуточные «звенья» от девелопера до пользователя предпочитают другие варианты :)

На раб. столе - роллинг, в продакшне - релизный (c) Андрей Ботезату

Сразу после очередного этапа активной разработки

Rolling, который сейчас творится в браузерной разработке - это кошмар

какой-то виндузовый опрос или ТС неизвестно что такое опенсорс?

А что такое этот «опенсорс»?

вдумайся в заголовок опроса

Никогда: только rolling release

Только rolling release и никакой некрофилии.

Да и черт бы с ним, с браузерным-то роллингом. Просто при фиксе 1.5 бага обычно только у Chrome-based-браузеров любовь выпускать новый «мажорный релиз», что, как ни забавно, не бесит.

долго думал что выбрать, ибо все ответы достойны и имеют смысл

в самом конце решился на «стабильность», и о чудо... почти половина решила так же!

Предпочитаю Ubuntu LTS - значит «С регулярными интервалами» мой вариант. Не люблю возиться с отвалившимся софтом и дровами... Работает и поддерживается? Отлично.

Когда достигнута стабильность

Нет.

Никогда: ещё программы и дистрибутивы «не нужны»

зря этот тупняк пропустили

Если исходники открыты, то о каком выпуске идет речь - заходи и бери в любой момент. Ну а если закрыты, то хочешь-не хочешь, а придется выпускать «с регулярными интервалами», чтобы баги закрывать. Тупой опрос.

какой глупый опрос и варианты глупые

А как отвечать, если: «как хочешь» и «как делаешь» два разных пункта? :)

Отвечать «как хочешь, чтобы делали».

Если исходники открыты, то о каком выпуске идет речь - заходи и бери в любой момент.

И тем не менее, многие проекты делают еще и релизы, несмотря на открытый доступ к репозиторию — и то и другое одновременно сейчас является стандартной практикой для открытых проектов. Если ты предпочитаешь наличие открытого доступа к репозиторию и при этом отсутствие релизов, то твой выбор «Никогда: только rolling release».

Когда разработчик посчитает нужным тогда пусть и выпускает. При этот результат должен стабильно работать.

Нужны и стабильные релизы и промежуточные.

Конечно я выбрал пункт «когда достигнута стибильность», но я вовсе не против, если на следующий же день будет night build, фиксящий серьёзную уязвимость! Так всегда бывает - готовят-готовят релиз, а потом васяпупкин находит в релизе дыру, причём оказывается, что он рапортовал о ней ещё 5 лет назад. :)

Один раз: когда разработка закончена