Ведение версионности

Разработка Far.
Post Reply
User avatar
ctapmex
Posts: 1240
Joined: Fri 11 Apr, 2008 07:53
Has thanked: 1 time
Been thanked: 50 times

Ведение версионности

Post by ctapmex »

Вопрос пошел от сюда https://github.com/FarGroup/FarManager/pull/397 .
Как то ранее упустил. В Far для задания версии используется структура

Code: Select all

struct VersionInfo Info = {Major, Minor, Revision, Build, Stage};
При попытке воспринимать её как классический SemVer, где Revision это patch, а Build - номер сборки, мы терпим не удачу. Т.к. тут Build скорее как patch, а Revision как номер сборки. В общем это не SemVer. По ссылке выше это объясняется как
Historically we identify changes by the build number and the revision was never used.
This is a preparation for a release branching model where a release branch can be cut from master any time and can potentially receive a few bugfixes, identified by the revision number only, while always staying the same feature-wise (and hence with the same "build").
Хорошо. Это путь фара так вести своё версионирование. Но эти же правила/ограничения накладываются и на плагины. При старте плагина надо в GlobalInfo->Version передать версию плагина, оформленную в VersionInfo структуру. И когда я передаю туда версию как 1.3.26.0 (Major, Minor, Revision, Build) полагая что это (Major, Minor, Patch, Build), far она воспринимается и отображается как 1.3.0.26. Что вводит в заблуждение, и расходится с информацией в свойствах dll файла.

вариант изменить GlobalInfo->Version на SemVer скорее всего не вариант. Хотя бы потому, что api уже устаканилось.
Тогда бы я предложил это явно описать в документации и примерах, что там есть https://api.farmanager.com/ru/exported_ ... infow.html .
И остается вопрос - где эта информация используется ? Все ли её воспринимают так же ? если у нескольких плагинов произойдет изменение в этом поле (получается резкий скачек версий) , ничего не сломается ?
User avatar
John Doe
Бюрократ
Posts: 13807
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 73 times
Been thanked: 426 times
Contact:

Ведение версионности

Post by John Doe »

ctapmex wrote: Tue 11 May, 2021 11:35 При попытке воспринимать её как классический SemVer, где Revision это patch, а Build - номер сборки, мы терпим не удачу. Т.к. тут Build скорее как patch, а Revision как номер сборки. В общем это не SemVer.
Значение каждого из компонентов версий нигде строго не определено, и отличается от проекта к проекту.
Тем не менее общепринятую тенденцию можно оценить например из ответов тут: https://softwareengineering.stackexchan ... r-revision

Как я посмотрю понимание major.minor.patch в основном семверовское, а build чаще всего уникальный номер, увеличивающийся с каждой сборкой (независимо от её причины).

А что у нас - понятия не имею. Но то что предлагается в исходном сообщении для меня выглядит необычно:
[...]can potentially receive a few bugfixes, identified by the revision number only, while always staying the same feature-wise (and hence with the same "build").
Т.е. предполагается что в каких-то условиях билд может оставаться прежним, а ревизия - изменяться.
https://t.me/FarManager — Telegram чат
User avatar
DrKnS
Posts: 6114
Joined: Thu 04 Aug, 2005 06:44
Location: Kyiv
Has thanked: 12 times
Been thanked: 426 times

Ведение версионности

Post by DrKnS »

User avatar
John Doe
Бюрократ
Posts: 13807
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 73 times
Been thanked: 426 times
Contact:

Ведение версионности

Post by John Doe »

Идея ясна.
С другой стороны, если переходить на человеческое версионирование, то номера билдов вообще не будут иметь прежнего значения, и достаточно их просто увеличивать. И то что иногда в 'старой' ветке может оказаться билд с большим значением чем в новой не кажется проблемным.
https://t.me/FarManager — Telegram чат
Post Reply

Return to “Development”