Разрабатывал проект, с чего начинаются мои номера версий?

Я разработал проект и многое изменил. Этот разветвление - это не просто небольшое изменение функции и исправление скрытой ошибки, это довольно существенное изменение. Только большая часть основного кода является общей.

Я разветвлял этот проект на v2.5.0. Некоторое время я начал создавать версии моего форка в версии 3.0. Однако я не уверен, что это правильный путь, главным образом потому, что когда этот проект выходит на v3.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 может указывать на младенчество, но verion 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)

Если это вообще возможно, верните вилку обратно в исходный проект. Я не могу подчеркнуть это достаточно.

Повторно набирая номера ваших версий, затем используйте тот, который вы разветвили, плюс суффикс даты.