Какая схема номера версии плохо запланированного, разветвленного, и шизофреничного приложения
Вам нужно получить значение модели вашего ActionResult, чтобы делать то, что вы хотели. Вы можете сделать это, приведя свой ActionResult к ViewResult и получив значение модели. Пожалуйста, обратитесь к принятому ответу на этот вопрос для более подробной информации.
7 ответов
По-моему, вы не хотите специально использовать номера версий. Вы можете использовать кодовые имена (Windows делала это с каждым из своих выпусков до их выпуска). По сути, вам нужно нечто большее, чем числа, чтобы отличить в доме , о какой отрасли вы говорите. По мере выпуска версий вы можете наклеить на них штамп Major.Minor.Revision, но до тех пор вам нужно называть их так, чтобы их можно было узнать.
Разделите их на ветви и дочерние ветви. Убедитесь, что у всего, что зависит от более высокой ветки, есть производное имя. Итак, вы можете назвать ветвь ProductionMac и ветвь ProductionWindows, и таким образом вы сразу узнаете, что их нельзя объединять и что они оба являются производными.
Самое важное, что нужно поддерживать, - это структурная иерархия , Номера версий неплохо справляются с этим, но вы должны продолжать добавлять "." для каждого нового слоя, который раздражает и совершенно не информативен (во многом похоже на присвоение имен вашим переменным variableOne, variableTwo, variableThree) Итак, убедитесь, что, как бы вы ни выбрали пометку каждой ветви, все же очевидно, какие ветви связаны с какими другими ветвями.
Похоже, что числа не очень помогут, я бы назвал релизы в честь маленьких пушистых зверюшек.
Или назовите каждый релиз в честь проекта, который его породил (' Переработка пользовательского интерфейса »,« Июньское обслуживание »и т. Д.), А затем присвоить ему номер версии, только когда он будет запущен?
Как предлагали другие, используйте внутри себя нечисловое кодовое имя и применяйте номер по мере выпуска каждого компонента.
Добавление номера версии / сборки к вашему управлению версиями может помочь вам сопоставить это внутреннее кодовое имя на внешний номер версии (и может помочь при взаимодействии с QA).
Например:
Соответствие правилам r1234 соответствует версии 1.1.0.1234.
Я бы использовал словарь для сопоставления между внутренними номерами разработки и внешними номерами" релизов ", а затем использовал бы внутренние номера разработки внутри и только покажите номера "релизов", когда будете готовы выпустить его из разработки.
Бонусные баллы, если вы используете промежуточную карту с иррациональными числами. "Как продвигается разработка версии 3.14159?" «О, неплохо, но я все еще исправляю ошибку, которую мы обнаружили в версии 2.71828183». «Что? Эта ошибка? Это должно было быть исправлено в младшей версии 1.73205!» : -)
На основании того, что вы описываете, я согласен с первой парой сообщений. Значимые, уникальные имена, относящиеся к области действия / набору функций, вероятно, подходят для каждой ветви. Пронумерованные версии кажутся разумными для каждой именованной ветки.
Что вам действительно нужно ... это маркировка в стиле Gmail ... для управления версиями!
уникальные имена, относящиеся к области действия / набору функций, вероятно, подходят для каждой ветви. Пронумерованные версии кажутся разумными для каждой именованной ветки.Что вам действительно нужно ... это маркировка в стиле Gmail ... для управления версиями!
уникальные имена, относящиеся к области действия / набору функций, вероятно, подходят для каждой ветви. Пронумерованные версии кажутся разумными для каждой именованной ветки.Что вам действительно нужно ... это маркировка в стиле Gmail ... для управления версиями!
nth-in the previous posts.
Наша система сборки увеличивает номер сборки после каждой сборки (независимо от того, будет ли она выпущена), что и используется разработчиками / QA для определить сборки. Окончательная версия # доступна ТОЛЬКО для внешнего мира при выпуске QA. Итак, действительно существует несколько сборок 1.3.0.x, но только одна настоящая 1.3.0.
Вот еще одна альтернатива, которую я рассмотрел вчера, взбивая это. Возможно, мне нужно переосмыслить то, что считается основным . Интеграция с другой системой может потребовать небольшого количества работы, но если это так сильно повлияет на планирование, даты выпуска и версию, как это имеет место для меня здесь, возможно, это само по себе достаточно большое влияние, чтобы поднять ветку до основной статус. Тогда часть моей головной боли будет сведена к минимуму.
Наиболее вероятные сценарии выпуска версий вне порядка вращаются вокруг второстепенных итераций. основные требуют скоординированных межведомственных усилий. Вы можете увидеть их на горизонте. второстепенные подкрадываются к вам и раскошеливаются.
"Вот новое соответствие правила. Если они не будут жить 15 июля нас оштрафуют на 500 000 долларов. В день "
" Что? Когда вы это получили? »
« В июле прошлого года. Разве вы не были на распределение? "
** facepalm **
Я по-прежнему считаю, что ответ Девинба является лучшим. Но я хотел рассказать об этом другим, столкнувшимся с этой дилеммой.
Peace | dewde