Що саме таке номер збірки в MAJOR.MINOR.BUILDNUMBER.REVISION

Що я думаю про номери збірки - це те, що щоразу, коли створюється нова нічна збірка, новий BUILDNUMBER створюється та призначається цій збірці. Тож для мого додатка версії 7.0 нічні версії становитимуть 7.0.1, 7.0.2 тощо. Це так? Тоді в чому полягає РЕВІЗІЯ після номера збірки? Або частина REVISION збільшується після кожної нічної побудови? Я тут трохи розгублений ... чи називаємо ми кожну нічну споруду БУДИНОК ?

Формат згадується тут: AssemblyVersion - MSDN

Я ніколи не бачив, щоб це було виписано в такому вигляді. Де я працюю, ми використовуємо форму MAJOR.MINOR.REVISION.BUILDNUMBER, де MAJOR є основним випуском (як правило, багато нових функцій або змін у інтерфейсі або базовій ОС), MINOR - це незначний випуск (можливо, деякі нові функції) на попередній основний випуск, REVISION, як правило, є виправленням попереднього другорядного випуску (без нової функціональності), і BUILDNUMBER збільшується для кожної останньої версії версії.

Наприклад, перегляд може бути переданий до QA (контроль якості), і вони повернуться із проблемою, яка потребує змін. Помилка буде виправлена ​​та повернена до QA з тим самим номером REVISION, але збільшеним BUILDNUMBER.

Вся плутанина випливає з різної семантики, яку MS використовує для "Build number" і особливо "Revision". Терміни просто означають різні речі.

Більшість людей (включаючи мене) використовують семантичну схему нумерації версій, де ви просто отримуєте більш високе БУДІВЕЛЬНЕ число, коли вам доведеться робити нову збірку з будь-якої причини. Для нас виправлення вважається лише черговою зміною коду, і частина BUILD збільшується автоматично з кожним запуском CI. Модулі з тим же MAJ.MIN.REV вважаються взаємозамінними, і BUILD повідомляє вам, який з них є останнім.

Зростання REVISION, однак, вказує на нову гілку постійного випуску, тому ми ставимо її перед BUILD. Мінусом цього підходу є те, що ми можемо отримати таку послідовність подій:

• номер 4711: Аліса додала функцію A
• CI виробляє збірку 1.2.3.100
• номер комітету 4712: Боб змінено функцію B
• номер 4713: фіксована функція A Alice ("виправлення")
• CI виробляє збірку 1.2.3.101

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

MS використовує обидва терміни по-різному. Номер BUILD не збільшується автоматично, замість цього його можна вважати видом гілки випуску, щоб заморозити код, який використовується для певної версії коду. ПЕРЕВІРКА вказує на додаткові "гарячі" зміни, застосовані до цієї гілки BUILD. Отже, послідовність буде такою:

• номер 4711: Аліса додала функцію A до магістралі / майстра
• Карл створює відділення для побудови 1.2.100
• CI виробляє збірку 1.2.100.0
• номер комітету 4712: Боб модифікував функцію B в магістралі / головному
• номер комітету 4713: Алісова фіксована функція А у 1.2.100відділенні
• CI виробляє збірку 1.2.100.1

Термін REVISION може позначатися

• продукт перегляд (це, як більшість людей використовують його)
• перегляд конкретної щоденної збірки (саме це робить MS)

Ключова відмінність між двома процесами полягає в тому, хочете ви чи ні, можливість застосовувати виправлення до збірок CI, і, таким чином, в який момент у процесі робиться гілка. Цей аспект стає важливим, коли ви хочете мати можливість вибрати конкретну збірку в будь-який час після того, як всі тести пройшли успішно, і просувати саме цю версію до наступного офіційного релізу вашого продукту.

У нашому випадку інструмент CI створює тег репозиторію, тому у нас завжди є необхідна інформація, готова до використання, коли це необхідно. З SVN стає ще простіше, оскільки теги та гілки реалізуються точно так само - тег - це не що інше, як гілка, розташована під /tags.

Дивитися також

З розділу FAQ на стратегії розгалуження TFS :

У якій гілці я повинен зафіксувати квиток P1 (виправлення)?

• P1 має бути зафіксований у гілці, найближчій до бази коду, що працює у виробництві. У цьому випадку P1 слід зафіксувати у відділенні Prod. Застосовуючи виправлення в будь-якій іншій галузі та виконуючи зміни у виробництві, ви ризикуєте звільнити напівфабрикат або неперевірений код від наступних ітерацій.

• Тепер ви можете заперечити, чи безпечно працювати безпосередньо проти гілки Prod, подумайте ще раз, P1, який потребує негайної уваги, не повинен бути принциповою проблемою в системі. У випадку, якщо це принципова проблема, її слід додати до нестабільності продукту, оскільки це може потребувати подальшого аналізу та обговорення із замовником.

Ще одне добре прочитане - посібник з розгалуження TFS

Microsoft описує призначення кожного компонента номера версії .NET у своїй документації MSDN для Versionкласу. Ось відповідна частина:

major.minor [.build [.revision]]

Компоненти використовуються звичайно:

Основні: збори з однойменною назвою, але різні основні версії не є взаємозамінними. Більш високий номер версії може вказувати на основний перепис продукту, коли зворотна сумісність не може бути припущена.

Незначні: Якщо назва та основний номер версії на двох збірках однакові, але номер другої версії відрізняється, це свідчить про значне вдосконалення з наміром зворотної сумісності. Цей вищий незначний номер версії може вказувати на точковий випуск продукту або повністю сумісну нову версію продукту.

Збірка: Різниця в кількості збірки являє собою перекомпіляцію того ж джерела. При зміні процесора, платформи чи компілятора можуть використовуватися різні номери збірки.

Редакція: Асамблеї з одним і тим же найменуванням, основними та незначними номерами версій, але різні зміни мають бути повністю взаємозамінними. Більш високий номер редакції може бути використаний у збірці, яка фіксує захисну дірку в раніше випущеній збірці.

http://msdn.microsoft.com/en-us/library/system.version.aspx

Є, принаймні, кілька різних речей, які я міг би уявити собі номер збірки:

1. Версія управління джерелом, яка була випущена. Наприклад, якщо відбувся випуск версії № 12345, це може бути відстежено, якщо він має бути номером збірки, і якщо він буде виправлений, це може змінити версію, оскільки це не нова функціональність, яка б збільшувала основні чи другорядні версії і номер збірки повинен запам'ятовуватися, якщо хтось захоче запустити цю збірку заново.

2. Ідентифікатор сервера безперервної інтеграції. У цьому випадку сервер CI може нумерувати кожну збірку, яку він запускає, і, таким чином, номер збірки - це те, що отримує успішна збірка, і частина перегляду не потрібна в цьому сценарії.

Можливо, є й інші, яких я не знаю, але це великі, які я знаю, коли мова йде про числа на кодових базах.

Кількість збірки зазвичай збільшується при кожній збірці, щоб вона була унікальною.

Для простоти деякі скидають номер збірки кожного разу, коли номери MAJOR або MINOR не стикаються.

Більшість двигунів безперервної інтеграції дозволяють створювати унікальні номери збірок.

Перегляд може використовуватися для виправлень складок. Скажімо, що над продуктом працюють 2 команди.

Команда 1 є основною командою розробників і виробляє нічні побудови за наступною версією схеми 1.0.X.0, де X збільшується. Тепер вони знаходяться на складанні 1.0.50.0 Команда 2 час від часу збирає збірку. Скажімо, вони беруть збірку з минулого тижня, яка становить 1.0.43.0, і починають її використовувати. Команда 1 просувається до 1.0.51.0, коли команда 2 виявляє проблему в 1.0.43.0.

Тепер команда 1 прийме цю збірку (43), виправить проблему та надасть команді 2 збірку 1.0.43.1. Виправлення може також розповсюджуватися в основній збірці, тому зміна з’явиться в 1.0.52.0.

Сподіваюся, це зрозуміло і корисно.

* Перегляд корисний, коли не кожен, хто бере участь у проекті, використовує однакову збірку і вам потрібно виправити конкретні збірки.

Дозвольте мені просто сказати, як я бачу і використовую це….

Версія ProgramName major.minor.build.revision

основні: Для мене це поточний проект, над яким я працюю. Число не зміниться, поки я не розпочну новий проект з такою ж назвою програми. Це означає, що я буду буквально писати нову програму тієї ж статі (приклад: доступ v1 - доступ v-2 - доступ v-3 * все та сама програма, але повністю переписана).

мінор: Це означає, що я додаю функціональність поточному опублікованому проекту. Наприклад, можливо, я додав можливість друкувати квитанцію або додав можливість імпортувати фотографії. В основному додаткову функціональність я хочу додати зараз, а не чекати наступного основного випуску, щоб зробити це.

build: Це я використовую, щоб вказати на дуже невеликі зміни у опублікованій версії major.minor. Це може бути зміна макета, кольорової гами тощо.

версія: Це я використовую для вказівки на виправлення помилок у поточному опублікованому major.minor.build - Бувають випадки, коли я не просуваю поточний проект, і виникає помилка. Цю помилку потрібно виправити та опублікувати. Це просто означає, що я фіксую те, що я вже опублікував, щоб працювати належним чином. Я також використав би це, якщо я працюю над новою збіркою, новим доповненням або запускаю нову основну версію. Опубліковану версію, очевидно, потрібно виправити, поки ми чекаємо наступного основного, другорядного чи версійного випуску.

Таким чином, готовий або зупинений проект все ще може бути виправлений та використаний до публікації наступного випуску.

Я сподіваюся, що це комусь краще зрозуміє, як працює (або повинен) цей тип версій. Для мене це єдине визначення та практика, яка має будь-який тип реального сенсу при використанні цього типу версій.

Я лише бачив номер збірки як останній номер в ідентифікаторі випуску. Я не впевнений, як ви придумали перегляд номера збірки. Я думаю, якщо ви змінили деякі небудовані ресурси (піктограми, скрипт DB тощо), можливо, але більшість проектів, над якими я нещодавно працював, також мають усі ці речі під контролем версій, тому процес збирання підбирає їх, коли зробити встановлення / випуск. Мені подобаються цифри збірки з часом, хоча це не так, як описує @David (мені подобається major.minor.revision.HHMM). Однак там, де я працюю, ми просто використовуємо послідовний номер, який генерує наш сервер побудови.

Як і jkohlhepp, ми використовуємо третю частину версії, щоб показати номер редакції в SubVersion, і четверту, щоб показати номер збірки з нашого сервера безперервної інтеграції (для нас Jenkins). Це дає нам декілька переваг - встановлення номера версії на нашому сервері CI видаляє вручну крок, який в іншому випадку можна випадково пропустити; легко перевірити, що розробник не зробив сміливого виходу зі свого ПК для розробки (в результаті чого ці цифри будуть нульовими); і це дозволяє нам прив’язати будь-який фрагмент програмного забезпечення до коду, з якого він був створений, і до роботи CI, яка його побудувала, просто переглянувши номер версії - який ми інколи вважаємо дуже корисним.

Це все, що ти хочеш. Я схильний використовувати year.month.day.hhmm для моєї основної.minor.build.revision. Якщо я виробляю більше однієї хвилини, щось не так. Ви можете просто використовувати простий приріст, або я бачив для них певні генератори. Що ти хочеш, щоб це було. Що їм потрібно зробити, це зробити так, щоб ви потрапили до джерела, використовуваного для створення цього виводу, тому все, що дозволяє вам це зробити.

Останні дві цифри - загальна кількість збірки

1.01.2.1234

кількість збірки становить 2.1234, проте більшість людей просто використовуватимуть 1234, оскільки 2 частина не змінюється часто.

Наша команда використовує третій номер (версію) як номер редакції з сховища Subversion. Ми використовуємо четвертий номер (build) як номер збірки з нашого сервера безперервної інтеграції TeamCity, який фактично створює збірку. TeamCity створює новий файл AssemblyInfo з потрібними #s в процесі збирання.