> Ну вот вы сами это написали. В чем разница с «верой в отсутсвие бога»?
Вера в Бога предполагает, что все в мире происходит по его воле.
Однако, в миропонимании атеизма и агностицизма Бог — это лишняя сущность, которая не требуется для объяснения законов мироздания и происходящих событий. Иными словами, для каждого события есть причина, и искать ее нужно не в Божественной воле, и не обязательно эту причину можно вообще выяснить.
Вопрос в том, что придется каждый коммит меткой снабжать или творить для каждого коммита ветки, а это лишняя работа в случае веток
Операции увеличения версии и проставления метки производятся автоматически скриптом релиза, который запускается ответственным за релиз. Сборка и деплой делаются полностью автоматически. Поэтому лишней работы здесь не видно.
Польза от меток — в из читаемости и последовательности.
Если есть метка, то по ней можно однозначно вычислить хэш коммита. Поэтому отдельная информация о хэше вроде как и лишняя.
Используем немного другой процесс, связанный с выпуском версий.
Ключевые моменты нашего подхода:
1. Номер версии — уникальный идентификатор. Если создается ветка, то это отражается в компоненте версии в виде уникального значения (например, «1.0.0.github»).
2. Источник номера версии находится в файле «version.txt», который может быть легко прочитан скриптом автоматической сборки/дистрибуции и не зависит от системы сборки.
3. Основанием для сборки является выпуск новой версии, при этом в Git-репозиторий добавляется метка (tag) со значением версии. Т.е. триггером сборки является появление метки. Метка является привычным маркером релиза для сервисов хостинга git-репозиториев.
4. Для автоматизации переключения версии написана небольшая кросс-платформенная утилита «verctl» (см. https://github.com/gelsrc/verctl/). По ссылке есть и описание утилиты, если это интересно.
Исходный код упомянутой утилиты является примером описанного подхода.
Исходя из этого, нам не нужно предоставлять информацию о хэше коммита, ветке и т.п., т.к. по нашим правилам версия однозначно соответствует исходному коду. И сам подход, собственно, не привязан конкретно к Git и Maven.
Однако, для вычитания это неверно: A — B != B — A (при условии, что A != B).
Так как в некоторых процессорах и микроконтроллерах используется неортогональный набор инструкций (https://en.wikipedia.org/wiki/Orthogonal_instruction_set), например, в том же Atmega AVR, известный по Arduino, то для операции вычитания требуются дополнительные затраты для размещения данных в подходящих регистрах/памяти.
Вера в Бога предполагает, что все в мире происходит по его воле.
Однако, в миропонимании атеизма и агностицизма Бог — это лишняя сущность, которая не требуется для объяснения законов мироздания и происходящих событий. Иными словами, для каждого события есть причина, и искать ее нужно не в Божественной воле, и не обязательно эту причину можно вообще выяснить.
Авторы хороших статей или комментариев тратят время (время == деньги), а некоторые и средства напрямую.
Операции увеличения версии и проставления метки производятся автоматически скриптом релиза, который запускается ответственным за релиз. Сборка и деплой делаются полностью автоматически. Поэтому лишней работы здесь не видно.
Польза от меток — в из читаемости и последовательности.
Если есть метка, то по ней можно однозначно вычислить хэш коммита. Поэтому отдельная информация о хэше вроде как и лишняя.
Можно предложить разные варианты.
1. Префикс метки Git: («v» — release, «d» — dev).
2. Суффикс метки/версии (например, «1.0.0» — release, «1.0.0.dev» — dev).
3. По количеству компонент версии (например, «1.0.0» — release, «1.0.0.0.0» — dev).
Если делается ответвление от ранее выпущенной версии (накладывается на нее фикс), то это можно выделить увеличением числа компонент.
Т.е. если базовая версия был «1.2.3», то на ее основе создается ветка «1.2.3.0», «1.2.3.1» и т.д.
Ключевые моменты нашего подхода:
1. Номер версии — уникальный идентификатор. Если создается ветка, то это отражается в компоненте версии в виде уникального значения (например, «1.0.0.github»).
2. Источник номера версии находится в файле «version.txt», который может быть легко прочитан скриптом автоматической сборки/дистрибуции и не зависит от системы сборки.
3. Основанием для сборки является выпуск новой версии, при этом в Git-репозиторий добавляется метка (tag) со значением версии. Т.е. триггером сборки является появление метки. Метка является привычным маркером релиза для сервисов хостинга git-репозиториев.
4. Для автоматизации переключения версии написана небольшая кросс-платформенная утилита «verctl» (см. https://github.com/gelsrc/verctl/). По ссылке есть и описание утилиты, если это интересно.
Исходный код упомянутой утилиты является примером описанного подхода.
Исходя из этого, нам не нужно предоставлять информацию о хэше коммита, ветке и т.п., т.к. по нашим правилам версия однозначно соответствует исходному коду. И сам подход, собственно, не привязан конкретно к Git и Maven.
Возможно, имеется ввиду, что: A + B == B + A.
Однако, для вычитания это неверно: A — B != B — A (при условии, что A != B).
Так как в некоторых процессорах и микроконтроллерах используется неортогональный набор инструкций (https://en.wikipedia.org/wiki/Orthogonal_instruction_set), например, в том же Atmega AVR, известный по Arduino, то для операции вычитания требуются дополнительные затраты для размещения данных в подходящих регистрах/памяти.