Ранний релиз или выдержанный?

[776166]

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

[temujin]

Я в выводах написал, что основная выгода от частых релизов для крупных проектов, в которых может быть коммерческий интерес у третьих сторон. Опять же есть оговорка, что когда мало изменений — график релиза не имеет смысла. И все же, тот же gzip иногда по несколько лет не давал о себе знать:

[ ] gzip-1.2.4a.tar.gz  1999-02-02 19:20    216K
[ ] gzip-1.3.9.tar      2006-12-15 03:44    1.6M

Вполне возможно, что это как раз был один из таких кризисов слишком длинного цикла релиза.

[776166]

gzip и кризис? :) Думаю, что по миру gzip в секунду запускается чаще, чем вносится коммитов во все репозитории.
Скорее всего, там максимум рефакторинг и специальные патчи, связанные с обновлениями ОС.

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

[temujin]

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

Я против этого и не спорю, всего лишь пытаюсь понять, где можно провести границу, за которой частые релизы помогают проекту.

[776166]

Скорее всего, вы не найдёте правильного решения: модель сложная. Надо учитывать очень много факторов от типа команды, её управления, личности владельца, до особенностей самого продукта и аудитории. И статистику для хоть какого-то анализа собрать сложно.

Хотя, безусловно, очень хотелось бы видеть серьёзные исследования на эту тему.

[temujin]

Такие исследования есть, но их крайне мало. Из них пара в ссылках. Выводы — за график, практика тоже — за график, крупные Open Source проекты в своей массе релизят именно так. Для небольших прикладных Unix-way утилит, вполне сойдет ad-hoc. Но где-то существует предел сложности проекта, когда пора менять стратегию. Граница линейкой не прочерчена, но она где-то проходит.

Вы знаете крупный OpenSource проект, в котором релизы не по оговоренному графику? Для меня только Apache веб-сервер непонятно как релизится а остальные — по расписанию.

[hurtavy]

Новые версии должны исправлять ошибки и привносить новые функции, а не выходить по графику

[Ruckus]

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

[temujin]

А почему или-или? Все это, но также придерживаться графика. Убунту — 6 месяцев, Гном — 6 месяцев, KDE — 5 месяцев, и т. д. Для крупных проектов, так целесообразнее, а когда работа не велась, то и релизить нечего. Никто не предлагает, чтобы ping обновлялся каждые 3 месяца.

[NeverIn]

Большое значение играет внешний или внутренний заказчик. Внешнему заказчику важны сроки для планирования своих бизнес-задач.