Как Вы делаете нумерацию версии в гибком проекте? [закрытый]
В итоге я запросил скрытые TextFields полей таксономии, используя термин ids:
<Where>
<Or>
<Contains><FieldRef Name='kf7aa880952e4699a9693b8b7379c884'/><Value Type='Text'>40e7b1fd-3892-4311-8428-6dbe77fc4ad7</Value></Contains>
<Contains><FieldRef Name='le11567cdf314372b377761db5f67b84'/><Value Type='Text'>40e7b1fd-3892-4311-8428-6dbe77fc4ad7</Value></Contains>
</Or>
</Where>
4 ответа
Я отслеживаю повторение гибких проектов, не повторение проектов программного обеспечения. Если последний параллельный проект начинающего присоединится то после другого проекта он будет поэтому init с текущим гибким повторением проекта, и не будет никакого неточного совмещения.
Для технического проекта за пределами домена гибкого проекта не должно быть возможно взаимодействовать с проектом в домене. Это было бы отказом премьер-министра процесса и должно быть устранено во всех случаях, где общая кодовая база используется с ветвлением, чтобы быть исправленной в соединительную линию как шаг очистки после завершения проекта.
Я предпочитаю Major.Minor.Build.Revision где Build - количество общедоступных выпусков, Revision - пересмотр от системы исходной версии
Я предпочитаю разделять сборку и процесс выпуска от процесса разработки команды, таким образом, я едва добавил бы повторение, спринт или подобный версии. Ваш случай является прекрасным примером о том, как со смешиванием обеих вещей не легко справиться. Что, если Вы изменяете методологию посреди проекта (независимо от того, что причина может быть)?
Отвечая Вам на вопрос, мы использовали Толпу в течение двух лет, и наш формат версии является классическим Майором. Незначительный. Обновление. Сборка (мы только используем Обновление на bugfixes). В конце это не обязательно для использования Номера сборки, поскольку Вам только нужен он для устранения неоднозначности различных пакетов от той же версии, но можно использовать другой символ, который представляет некоторую Частную Версию.
Лично я считаю, что управление версиями, которое мне больше всего понравилось, - это полное избавление от всего major.minor . Я думаю, что это реально возможно только для внутренних приложений, но в этом случае это значительно облегчает жизнь.
Обычно, если вы разрабатываете внутренние приложения, я заметил, что бизнес на самом деле никогда не заботится о том, какие основные / минорная версия, которую они используют. Вместо этого они, как правило, хотят знать: а) когда выйдет следующий релиз и б) что будет, а что выйдет - вот и все. Пытаюсь сохранить тот факт, что вы работаете над FOO-4.34.0.1-a и BAR-3. 19.4.1 , когда никому нет дела, только усложняет общение.
В предыдущей группе у нас действительно не было крупных релизов, кроме начала проекта. Каждый выпуск был таким же «мажорным», как и предыдущий.
В результате, я думаю, они поступили разумно и вместо этого сообщили бизнесу как PROJECT_RELEASENUM . Номер выпуска увеличивался на «1» каждый раз, когда мы делали выпуск, с исправлениями как PROJECT_RELEASENUM_PATCHNUM , который также увеличивался на «1».
Это хорошо сочетается с представлением о том, что разработка осуществляется как непрерывная серия спринтов, пока бизнес не получит всю необходимую функциональность (чего на практике никогда не бывает - всегда есть что-то , что они хотят ). Владельцы бизнеса это понимали, разработчики могли это сообщить, и это естественно соответствовало нашей модели непрерывного развития.