Коли зобов'язання не має позначати версію?

30

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

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

— VortixDev
джерело

23

Чи кожен зобов’язаний освоїти стабільний, перевірений, якісно забезпечений реліз у вашому проекті?

— Алекс Рейнкінг

1

@AlexReinking Кожна фіксація перевірена, але я просто намагаюся звикнути до звичайних практик з моїми особистими проектами, тож я просто працюю над цим, і як такої насправді не існує іншої системи, ніж "внести зміни, перевірити це сам, вчинити ».

— VortixDev

Також зауважте, що теги можна змінити пізніше. Єдиний ідентифікатор твердої фіксації твердих фактів - хеш-ключ фіксації.

— Thorbjørn Ravn Andersen

9

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

— xyious

2

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

— BJ Майєрс

71

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

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

— Алекс Рейнкінг
джерело

5

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

— Qwertie

5

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

— Алекс Рейнкінг

5

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

— Залізний Гремль

11

@Qwertie - стримуйте оновлення. Скільки людей досі працюють із старими основними версіями Windows та Office?

— Алекс Рейнкінг

5

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

— Залізний Гремль

11

Номери версій розподіляються до випусків. Загалом, не кожне зобов'язання повинно бути випуском. Для цього є кілька причин.

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

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

Наслідком цього є те, що ви повинні додавати функції до свого "загальнодоступного API" у повному обсязі (не в альфа-бета-версії), якщо ви готові підтримувати ці функції у їхньому теперішньому вигляді.

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

— Пітер Грін
джерело

2

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

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

Однак, все більше грає:

Один із способів бути впевненим у цьому - збивати номери версій з кожним комітом, але це, як правило, не є хорошою ідеєю. Для відносно невеликої зміни може знадобитися кілька комітетів / ітерацій, і зовнішньому світу це заплутано, щоб побачити версію 0.0.1 -> 0.0.2 внаслідок великої кількості накопичених змін, а потім 0,0.2 -> 0,0 .56, оскільки хтось, що вчинив пробіл, виправляє один файл за один раз і нічого не змінює.

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

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

— НІ хто
джерело

0

Кожен запит на витяг, який об'єднується з головним, повинен бути обґрунтований.

Якщо це не повинна бути нова версія (принаймні патч), вона, ймовірно, не повинна бути об'єднана в головну, оскільки функція / fix / etc не є повною.

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

— химерний
джерело