Дата як номер версії програмного забезпечення

Зазвичай розробники програмного забезпечення не використовують дату як номер версії, хоча формат YYYYMMDD (або його відхилення) виглядає досить міцним для використання. Чи щось не так у цій схемі? Або це стосується лише обмежених "типів" програмного забезпечення (наприклад, власних виробництв)?

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

Взагалі, ваші клієнти не будуть дуже піклуватися про те, яким буде номер версії програмного забезпечення, якщо вони знають, що вони працюють дещо новіше (тобто Продукт 2012 новіший, ніж Продукт 2010), і що вони це знають є актуальним, якщо є виправлення, які можна розгорнути (наприклад, продукт 2012, оновлення 10). Таким чином, з точки зору брендингу клієнтів я вважаю за краще віддавати або названі версії (наприклад, Windows XP, Windows Vista) з подальшим суворим порядковим числом патчів, які можуть бути встановлені користувачами.

Однак, написання програмного забезпечення, яке перевіряє зручності для користувача, як правило, робить код під капотом набагато складніше написати. Таким чином, я, як правило, віддаю перевагу простій Major.Minorсхемі версій хоча б тому, що ви можете зробити просте порівняння чисел, щоб перевірити, чи є щось актуальним, як у наступному:

// Check to see if we can handle the file version
if (this.Version < fileVersion) {
   throw new UnsupportedFileException("The file version is " + fileVersion.toString() + " which is not supported");
}
// Do stuff ...

Однак, щоб це було трохи в контексті, я, як правило, не байдуже, наскільки велике отримує незначне число (тобто 1.1024), що дозволяє вищевказаній системі продовжувати успішно працювати. Взагалі ревізійні номери цікавлять лише внутрішній розвиток, і я насправді навіть не бачив, як вони впливають на речі, що набагато перевищують лише надання речей додаткового числа для відстеження.

Однак вищевказані дві схеми дійсно не застосовуються лише до середовищ, де використовується безперервне розгортання (тобто Stack Exchange), і саме там я, як правило, віддаю перевагу певній даті з наступним номером ревізії, як видається, що використовується на Stack Exchange сайти. Причиною цього є те, що версії будуть занадто часто змінюватися в середовищі безперервного розгортання, і ви можете мати кілька версій коду, що з'являються в один і той же день, що виправдовує номер версії, а поточна дата є такою ж доброю, як і будь-яка для розбиття речей ще більше. Теоретично ви можете просто скористатися номером версії для всього, але використання поточної дати дозволяє внутрішньо відслідковувати основні етапи, які можуть полегшити обговорення.

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

"Цей фрагмент функціоналу повинен бути у випуску 1. Інший фрагмент функціоналу повинен бути у версії 2."

Ви не можете вказати дату в специфікаціях, оскільки дата випуску може бути пропущена.

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

Номери версій навряд чи містять дати, оскільки їх контекст пов'язаний із специфікаціями.
Номери складання, ймовірно, містять дати, оскільки їх контекст пов'язаний з тим, коли відбулася збірка.

Хоча цей підхід має переваги, як ви описали, є певні недоліки, якщо ви використовуєте дату як номер версії:

• Версії на основі дати плоскі. За допомогою v2.1.3 ви можете бачити номер версії, номер під-версії та номер під-версії. З 20110119 ви можете бачити лише коли було написано. Ви можете згрупувати свої датні версії за місяцями, але це все одно не скаже вам нічого. У вас може бути кілька повільних місяців виправлення невеликих помилок, а потім два тижні важкого кодування, що призводить до значного випуску. Дати вам цього не говорять, звичайні номери версій.

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

Версії часто використовуються для передачі інформації про те, чим відрізняється певна версія програмного забезпечення від попередньої. Так, наприклад, якщо ви модернізуєте від 1,0 до 2,0 Acme, це є основним оновленням, теоретично воно має суттєві зміни.

Оновлення з 1,0 до 1,1, з іншого боку, є незначним оновленням і теоретично вносить незначні, поступові зміни та виправлення помилок.

Це було б важко представити у форматі дати, хоча ви можете використовувати суміш. Наприклад, v1.0.YYYY.MMDD

Не повторюючи гарних ідей з інших відповідей, я маю на увазі проблему, яка ще не була вирішена.

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

Наприклад, ядро ​​Linux було передано близько 2000 року в стару гілку 2.4.x, яка, ймовірно, підтримується сьогодні і нараховується як 2.4.199, тоді як нова версія була 2.6, протягом багатьох, багатьох років і становить 2.6.32 для старих систем, але 3,2 для найновіших ядер.

Якщо у вас є документація про ваші випуски, ви подвоїте інформацію та скажете людям, що версія 20120109 надійшла в 2012 році 01/09. Mh. Але що, якщо буде виявлено помилку в останній момент, і випуск затягується на тиждень, але документація, де згадується ім’я, вже готова, можливо, надрукована, інформація про пресу вийшла тощо. Тепер у вас є розбіжність, яка є проблематичною, якщо версія 20120109 надійшла в 2013/01/13.

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

У Ubuntu зі своєю схемою 04/10 виникли проблеми у 2006 році, коли версія 6.04 затрималась і стала 6.06. У 3000 році скоро з’явиться наступна проблема! :)

Існує багато програмних пакетів, які дійсно використовують дату як версію. На думку Ubuntu, де їх версія - YY.MM. А номери збірок для продуктів Microsoft Office також є кодуванням дати складання. Джефф Етвуд написав блог Coding Horror про нумерацію версій , включаючи цю рекомендацію:

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

На мою думку, це не має значення, поки ви консистент і можете перейти від номера версії збірки (що б це не було) і пригадати всі артефакти, які потрапили в цю збірку з вашої системи управління версіями. Користувачів, як правило, не цікавить інформація про версії, а швидше функціонал, який надає система. Інформація про версії представляє лише реальну цінність для розробників.

Використовуйте семантичну версію - таким чином ви отримуєте деяке уявлення про тип змін, що вносяться між версіями, без необхідності перевіряти сам код: http://semver.org/

Використання номерів версій - це спосіб показати, наскільки великі зміни

Наприклад, 2.4.3 може означати, що версія 2 є головною зміною для всієї системи. .4 - незначне оновлення. і останнє .3 - це невелике виправлення помилок у цій версії. Таким чином, його легко впізнати, скільки змінилося між кожною версією.

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

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

Іншими словами, я говорю про ситуації, коли немає фактичного "номера версії", а в основному свого роду квазіденний дамп для сховища.

Коли я стикаюся з подібними матеріалами, я зазвичай вітаю вибір, оскільки мені корисніше знати, що я використовую відносно поточний сценарій / lib, а не конкретну версію.

Дати як номер версії хороші для маркетингу. Якщо люди використовують "Windows NT 5.0", вони можуть не усвідомлювати, що це застаріло. Але якщо люди все ще використовують "Windows 2000", вони негайно зрозуміють, що це 12-річна ОС, і їх рекомендують оновити.

Однак це робить важче розрізнити "основні" та "незначні" оновлення.

Проблема з використанням дат як номерів версій

Відповіді тут хороші, але я не бачив, щоб хтось вирішував цю проблему з використанням дат: Користувач не може визначити, як часто вносилися зміни.

Що я намагаюся сказати, це те, що я можу сказати, що Windows 3.1 і Windows 7 далеко один від одного ... і, можливо, несумісні. Windows 95 та Windows 2000 не підказують мені більше, ніж рік, коли продукт був представлений.

Наприклад, з Python я знаю, що версія 2.7.2 розвинулася з 2.4.6. Якщо я дивлюся далі, то бачу, що версія 2.4.6 була випущена 19 грудня 2008 року; і ця версія 2.7.2 була випущена 11 червня 2011 року. З цього я можу сформувати думку про стабільність (тобто частоту випуску) продукту.

Якщо замість цього Python використовував дати випуску, я не можу знати, як ці продукти можуть бути пов'язані. Подальша плутанина призведе до того, що Python 3.1.4 також був випущений 11 червня 2011 року (те саме, що і Python 2.7.2).

Коротше кажучи, я не думаю, що саме по собі дата-версія є цінною.

Мені не подобається ця ідея з причин, які вже описали інші. Просто використовуйте схему major.minor.bugfix - є причина, чому більшість людей роблять це саме так.

Але що б ви не робили: виберіть одну схему іменування версій та дотримуйтесь її . Не робіть це як Windows, де вони змінюють схему з кожним випуском. І не робіть це як Android, де кожен випуск має номер версії API (8), номер версії, призначену для маркетингу (2.2) та дурне ім’я (Froyo).

Дата як версія

Якщо ваш товар не продається, то просто використовувати дату - це добре і, ймовірно, корисно. Якщо ви продаєте його та модернізуєте клієнтів, вони хочуть придбати модель із певним набором функцій. Набагато простіше продати їх на апгрейд, якщо ця модель має чітку назву, це не дуже важливо, що це таке, але, наприклад, ніхто реально не купує 2012 січня 20-го автомобіля Ford вони хочуть Kia Model будь що. Те саме стосується програмного забезпечення. Надавши назву та версію жорсткої моделі, це означає, що вона має особливості, що відрізняються від старої. Для мене просто побачення цього не робить, воно говорить, що я це зробив тоді, не може це мати нові функції.

Схему, яку ми використовуємо

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

1200_GLD_120120_F0D1

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

Тож у нас може бути послідовність

1200_TST_120110_EF45
1200_GLD_120120_F0D1
1201_FIX_120125_123E
1201_TST_120130_31A5
1201_TST_120131_FDFD

Ми зазвичай зазвичай посилаємось на основні номери версій до клієнта, тобто "12", але клієнт отримає останню версію золота 12, тобто 1200_GLD_120120_F0D1, якщо їм не потрібна помилка.

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

Скажімо, остання версія другої версії 2.3.2, а третя версія - 3.0.3. Тепер ви виявляєте вразливість, яку абсолютно потрібно виправити, тому ви випустите 2.3.3 та 3.0.4 в той же день. Чи можете ви бачити, як дата виходу абсолютно не має значення? Можливо, у 2013 році ви припинили роботу над другою версією та випустили лише деякі основні виправлення помилок. Дата не має значення в порівнянні з номером версії.

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

Це може працювати не у всіх випадках.

Технічно він не може використовувати дату для номера версії, але може відображати номер дати для клієнта. Наприклад, macOS 16.7.23 --- це означає, що: 23/7/2016

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

Номер будинку виглядає як машина, машина, ні жива, ні жива.