Как вы управляете выпуском версий приложений?

Например, есть релиз приложения версии 1.3 и есть план: выпустить след. версию (например 1.3.1) дабы пофиксить найденные проблемы, разработать новую версию с новыми возможностями (1.4), доработать версию 2.0a чтобы начать публичное тестирование и, наконец, сделать что-то с теми кто уже 10 лет сидит на 1.1.8 final и хочет сидеть ещё столько же. Как вы всем этим управляете? Куча копий версий или новый релиз — фикс старых багов, новые возможности и новые баги, а остальное гори огнем? (под "вы" подразумевается не обязательно чистая шаравара)

Расскажите.

Здравствуйте, о_О, Вы писали:

о_О>Как вы управляете выпуском версий приложений?

о_О>Например, есть релиз приложения версии 1.3 и есть план: выпустить след. версию (например 1.3.1) дабы пофиксить найденные проблемы, разработать новую версию с новыми возможностями (1.4), доработать версию 2.0a чтобы начать публичное тестирование и, наконец, сделать что-то с теми кто уже 10 лет сидит на 1.1.8 final и хочет сидеть ещё столько же. Как вы всем этим управляете? Куча копий версий или новый релиз — фикс старых багов, новые возможности и новые баги, а остальное гори огнем? (под "вы" подразумевается не обязательно чистая шаравара)

о_О>Расскажите.

Добрый день.

Транк, бранч, лэйбл в TFS.

Здравствуйте, Neud, Вы писали:

+1 , но лучше что-то из DVCS IMHO: Git или Mercurial — легче мерджить будет изменения trunk<->branches(label/tags).

N>Добрый день.

N>Транк, бранч, лэйбл в TFS.

У нас не однократно поднимается тема с GIT, а баги, кейсы оставить в TFS. Пока думаем

Ставите систему контроля версий. Хотя и так наверное есть. Я пользую SVN.

Допустим вся текущая разработка идёт в трунке. Выпускаете 1.3 тут же создали бранч 1_3 и продолжаете работать в трунке — новые фичи для версии 2.0 и всё такое.
Нарисовались какие то баги в релизной, вы их можете править допустим в бранче 1_3 — после исправления, мержите в трунк. Мерж возможен как автоматом, так и вручную. 1_3 можно так и оставить и не создавать ещё одну 1_3_1. Всё равно отдельного развития у 1.3 и 1.3.1 не будет.

У меня есть ветки 1_0, 2_0, 3_0, 3_3 и т.д. иногда бывает полезно помотреть как раньше работало или кому то старую версию подогнать по спец цене. Фиксы в старые и не актуальные версии понятно уже не идут.

Для 10.0 наверное вообще одтельная ветка, там у вас видимо только отдельные компоненты одинаковые с 1.3 и как их мержить х.з.

о_О>Как вы управляете выпуском версий приложений?

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

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

Я всех загоняю на последюю версию с доплатой. НИКТО за 10 лет не ругался. Старое не чиню — не выгодно.
Среди кастомеров админы и девелоперы разных фирм больших и малых.