Page 1 of 1

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

Posted: Tue 11 May, 2021 11:35
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 .
И остается вопрос - где эта информация используется ? Все ли её воспринимают так же ? если у нескольких плагинов произойдет изменение в этом поле (получается резкий скачек версий) , ничего не сломается ?

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

Posted: Tue 11 May, 2021 12:11
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").
Т.е. предполагается что в каких-то условиях билд может оставаться прежним, а ревизия - изменяться.

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

Posted: Tue 11 May, 2021 13:07
by DrKnS

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

Posted: Tue 11 May, 2021 14:25
by John Doe
Идея ясна.
С другой стороны, если переходить на человеческое версионирование, то номера билдов вообще не будут иметь прежнего значения, и достаточно их просто увеличивать. И то что иногда в 'старой' ветке может оказаться билд с большим значением чем в новой не кажется проблемным.