Типа как опера постоянно выпускает недельные сборки своего браузера?

вы имеете ввиду частые _релизы_ или частые _билды_ ?

Не могу ничего ответить по сути вашего вопроса, но я думаю что тут могут быть 2 случая:
1) Раздражение от того, что все время что-то не работает, приходится обращаться постоянно к разработчикам и фиксить ошибки. По сути - выполнять работу, которая мне не нравится, но отнимает время и не платят за нее деньги.

2) Появление ощущения своей причастности к разработке программы, её отладки и т.д. А это может вылиться в привязанность к продукту и появлении бесплатного пиар-ресурса.

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

Если компания параллельно с мелкими релизами не готовит что-то грандиозное - дела продукта плохи. Модернизируя каждые несколько месяцев самолет (который каждый раз летает и даже лучше прежнего) мы на Луну не улетим никогда :-)

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

Small Releases предназначены для заказчика (customer) в том смысле, в котором это опредляет методология XP, то есть пользователя, или группы пользователей, интересы которых решает продукт, но при присутсвии заказчика релизить продукт в обычном смысле этого слова, наверняка, не стоит. В идеальном варианте заказчик практически является частью команды, и его задача - эти самые релизы оценивать.

Да, Opera, похоже, идет по пути публикации своих релизов для широких масс, ибо заинтересованы в ранних билдах браузера в основном хорошо прокачанные веб-мастера, которые, в частности, могут дать адекватные оценки билдам. Частые публичные релизы в этом случае одновременно интегрируют в команду разрабочтиков армию хороших тестеров и берегут нервы оных. Если их завалить фичами, они просто не успеют их все пощупать.

Вы, кстати, планируете заняться, и потому разбираетесь, или уже практикуете?

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

в каком-то смысле это, действительно, бета-тестинг. Но. публичный бета-тестинг подразумевает очень и очень приличное внутреннее тестирование. То есть как минимум регресии нет, а все новое "в основном работает"

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

Многий софт с частыми релизами я просто не обновляю, допустим download master - там обновлять уже и добавлять нечего. баги они все-равно не правят - сколько не писал я на форуме
А вот например miranda-im я обновляю сразу - появляются новые фичи, исправляются ошибки - и все полезно.

Лучший на мой взгляд выход - давать пользователям доступ к nightly builds, а сами релизы проводить не очень часто

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

Никакого. Но пользователи скорее всего заинетересованы в развитии продукта. Существует опасность, что если команда нацелена на выпуск одного большого релиза в квартал, например, то продукт будет развиваться слишком медленно. Всегда можно сказать — это пойдёт в следующий релиз, в этот уже не успевает собрать и тщательно оттестировать. Ах, релиз через пять месяцев? Ну, простите. И даже такая медлительность не спасёт пользователя от недотестированных багов. Неделя до релиза, и вдруг всплывает критичная проблема или безумно нужная заказчику новая функциональность. Всё равно в релиз что-то добавят, даже с риском продлем на продакшене. Так не лучше ли сразу работать в представлении, что релизиться надо часто?

> Мне представляется, что короткие релизы не позволяют планировать заранее большие изменения. Насколько такая практика способствует (или не способствует) сохранению идейной и архитектурной целостности продукта?

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

И ещё — сложности возникают только при строго последовательной разработке, но кто мешает её распараллелить? Тогда можно часто релизить мелочёвку, и редко — что-то большое и прекрасное.

Я сама именно по такой схеме работаю (http://www.control-freak.ru/tag/packages/), и — получается ведь.