Запропонований проект, звідки починаються номери моїх версій?

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

Я відправив цей проект на v2.5.0. Якийсь час я розпочав версію свого вила на v3.0. Однак я не впевнений, що це правильний шлях, головним чином тому, що коли цей проект потрапляє в версію 3.0, речі стають заплутаними. Але я не хочу починати з v1.0 або v0.1, тому що це означає немовля, нестабільність та невідповідність проекту. Це неправда, оскільки більшість основних кодів є дуже досконалими та стабільними.

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

Більшість вилок, які я бачив, починаються знову з версії 1.0. Але я припускаю, що ви також змінили назву своєї вилки, тому я не впевнений, чому виникне плутанина, якщо ви просто почали з v3.0.

Що б я зробив, це змінити назву проекту, випустити версію 1.0 і дати зрозуміти, що проект є вилкою іншого проекту. Я не думаю, що з цим підходом не буде плутанини.

Якщо ви дійсно переживаєте за етикетку "1.0", просто випустіть версію 2.0 через короткий час після 1,0 ...

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

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

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

Дивіться: http://kb.askmonty.org/v/mariadb-versus-mysql

Примітка. Оскільки ця відповідь була розміщена, MariaDB суттєво відхилилася від MySQL і тепер дотримується власної схеми версій.

0,1 може вказувати на немовля, але версія 1,0+ означає стабільність. Збільшення числа основних версій, наприклад, 2.0, 3.0, як правило, вказувало на велику зміну функції.

Напр

• Версія 1.0 моєї програми була інструментом для запуску тестових сценаріїв із налаштуванням,
• Версія 2.0 усунула диференціацію між тестовими сценаріями та сценаріями настройки середовища,
• Версія 3.0 додала графічний інтерфейс для написання сценаріїв як графіків потоків. Вони є різними продуктами, але навіть версія 1 була робочим продуктом, повністю стабільною і т. Д. Версії 2 і 3 виникли, оскільки було вирішено, що ці великі зміни будуть добре. Якби ми не хотіли цих великих змін і просто продовжували робити виправлення помилок тощо. Малі номери версій тільки збільшились, 1.10,1.20 тощо, і це було б добре.

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

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

• Спочатку: " MyFork v1.1 (заснований на OrigProg v3.0)
• Деякі поліпшені мережі, внесені до MyFork: MyFork v1.3 (на основі OrigProg v3.0)
• OrigProg випустив основну версію, а MyFork витягнув і об'єднав: MyFork v2.1 (на основі OrigProg v4.0)
• Внесла деякі основні зміни в MyFork (напевно, не вдасться знову легко злитися з OrigProg): MyFork v3.0 (на основі OrigProg v4.0)

Якщо це можливо, з’єднайте виделку назад до оригінального проекту. Я не можу наголосити на цьому достатньо.

Перевіряючи номери версій, використовуйте ту, яку ви роздвояли, плюс суфікс дати.