Политика в отношении корректировочных версий по сравнению с нормальными выпусками?

Клиент на первом месте. Вам придется мириться с поддержкой нескольких версий вашего программного обеспечения, потому что некоторые клиенты просто не будут обновляться. Это досадный факт жизни. Вы можете несколько смягчить его в некоторых областях разработки программного обеспечения (например, веб-приложения - кто-нибудь все еще использует исходную версию Gmail?), Но даже в таких средах тонких клиентов люди все равно не будут обновлять тонкий клиент (IE6 кто-нибудь?) .

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

Я не уверен в этом »

К сожалению, это то, что вам нужно решить, прежде чем подписывать какие-либо контракты с вашим первый покупатель. Если этого нет в контракте, значит, его не существует.

На термоусадочную пленку не стоит обращать внимания. Контракта нет, поэтому вы не обязаны оказывать какую-либо поддержку. Вне зависимости от желания поддерживать хорошие отношения. Дело в том, что вы уже получили свои деньги от прошлого клиента. Поддержка их на неограниченный срок в мгновение ока сократит уже получаемую прибыль до нуля. Если вы действительно хотите перейти на сервисную модель, вы не сможете продавать программное обеспечение в термоусадочной упаковке. (Подумайте об антивирусном программном обеспечении. Вы перестаете платить, они перестают обновляться.)

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

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

Мы создаем только одну версию для наших клиентов, и мы делаем ежедневную сборку и модульное тестирование (у вас есть и то, и другое, не так ли?)

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

Edit: Когда дело доходит до ситуации « OMG, наша функция на полпути, но нам все еще нужно выпустить ее сейчас, и да, я имею в виду СЕЙЧАС ! "мы бы просто пометили новую функцию (с помощью директивы препроцессора ) и убедились, что во время сборки весь код внутри тега просто закомментировал.

у нас есть как сервисные, так и обычные выпуски.

Предположим, мы работаем над выпуском 5.5, и клиент обнаружил, что некоторые проблемы в предыдущей версии могут быть в 5.4.0.1, мы предоставим им решение в версии 5.4.1.0, а также внесем изменения в нашу текущую версию, то есть 5.5. Таким образом, мы пытаемся закрыть предыдущие проблемы в текущем выпуске, а также предоставить новый комплект клиенту в старом выпуске

Следующий рабочий процесс может помочь вам (но YMMV):

1. Создайте ветку темы для исправления ошибки, разветвив ее в самом раннем месте (например, выпуск 1.0), с именем например, 'foo-bugfix'
2. Создайте новую ветку для служебного выпуска для версии, например 1.0, если она еще не существует, и если в этой версии есть ошибка, с именем e., g. 'maint-1.0'
3. Объединить ветвь исправления ошибок с веткой обслуживания, разрешив конфликты, если таковые имеются.
4. При необходимости измените номер версии. Отметьте новый отладочный выпуск, например, «1.0.1»
5. Повторите 2–4 для других версий, которые вы хотите поддерживать

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

Я предлагаю прочитать Контроль версий для нескольких Agile-команд и особенно раздел Release Branch (то, что работает для N команд, работает и для 1 команды).

Из того, что я прочитал в различных ответах и ​​комментариях, вы можете найти в нем несколько полезных советов.

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

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

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

Если у клиента все еще есть проблема с вашим текущим выпуском, и это срочно, он может получить «исправление». Если текущий выпуск - 1.2, исправление может быть включено в предварительный выпуск 1.3, который предоставляется заказчику. Этот заказчик срочно сейчас помогает вам протестировать нестабильный точечный выпуск, а также может предоставить отзывы о некоторых других изменениях в точечном выпуске. Создание небольшого выпуска с одним исправлением, которое вы снова объединяете с ожидающим выпуском, после того, как ваш клиент помог вам протестировать его, также является вариантом.

Это можно сравнить с методом пакета обновления Microsoft: часто выпускайте исправления, а затем собирайте их вместе в пакет обновления (-> точечный выпуск). Перед тем, как исправления для широкого выпуска часто тестируются вместе с клиентами, сталкивающимися с проблемами, патч должен исправить.

Чего вы определенно хотите избежать, так это наличия «1.0.1-клиента A» и «1.0.1-клиента B». вызов сложности и аду обслуживания.

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