Чи швидка основна версія натрапляє на свідчення поганого дизайну?

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

Одне, що я помітив, - це те, що основна версія системи вже є 11.YZ Форма мого досвіду роботи з іншими системами та бібліотеками, я не пам'ятаю, щоб продукт швидко натикався на основну версію. Є продукти, які роками перебувають у 1.XY та все ще отримують функції та виправлення.

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

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

Не обов'язково.

Ви згадували в коментарях, що це внутрішній API. Порушення API погано, тому що ви порушуєте код кожного. Але для внутрішнього API "всі" - це лише "ви", і ви цілком здатні координувати такі зміни API з самим собою, тому біль, яка зазвичай пов'язана зі змінами API, значно гірша.

Крім того, середній показник може бути масово введеним в оману: можливо, у них відбулося 11 проривних змін API протягом перших двох днів раннього розвитку, і вони були стабільними протягом 4 років? SemVer дає змогу вносити зміни, не збільшуючи основне число, якщо основне число дорівнює 0, але це не змушує вас робити це. Можливо, вони почали використовувати SemVer з 0 дня, навіть на етапах прототипування / дослідження?

Коротка відповідь

Ні

Довга відповідь

"Іноді число - це просто число"

Забудьте про "семантичну версію", "раціональність", "логіку" в сучасному шаленому світі

Чому Chrome так швидко збиває номери версій?

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

При використанні семантичного версії все ще приймається рішення про те, які зміни вважаються "основними", а які "незначними". Існують різні причини збивати номер версії - або не збивати її.

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

В іншому випадку у вас фактично є розклад випусків (думайте про щоквартальні оновлення компакт-дисків, що надсилаються клієнтам), де є сенс змінити основний номер версії, щоб замість "Версії 3.4 / 16 жовтня" просто сказано "Версія 11.0". В даний час все більше і більше програмного забезпечення випускається з короткими інтервалами, що робить графіки випуску менше причин дотримуватися певної схеми версій. Я бачив це у великих складських системах, які дозволяють внутрішньому ІТ лише один день простою в квартал (як правило, в неділю). Цей день є днем ​​розгортання і кожного разу відзначається новою основною версією.

Деякі програми мають зовнішні залежності, які мають надзвичайно важливе значення, оскільки користувачеві доведеться оновлювати обидві одночасно. Якщо у вас є Word-addon, який працює лише з Word 2010 та ще один для Word 2013, можливо, ви захочете синхронізувати ваші основні номери версій з номером MS-Word. Тут важливі основні цифри, тому що деякі ваші користувачі будуть "позаду" вашого звичайного розкладу оновлень, оскільки вони не оновлювались до найновішої версії Word (або будь-якого іншого, на що ви покладаєтесь: SAP, Dynamics, тощо).

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

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

Консенсус щодо значення номерів версій дійсно є головним.minor.revision.buildnumber

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

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

• Продажі знижуються, клієнти / користувачі чекають наступного великого випуску перед оновленням.

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

• Конкурент X був у грі трохи довше, тому їх основний номер версії просто виявляється вищим, ніж ваш. Це робить його схожим на те, що ви відстаєте, вам доведеться «наздогнати».