Привет тем, у кого уже утро понедельника
Первый вопрос
Во многих репозиториях вижу ветки:
release/1.0
release/2.0
release/3.0
Это как-то связано с тем, что SourceTree такие ветки группирует?
Или это не только SourceTree такое может делать?
Второй вопрос
Если такая стратегия именования действительно связана с группировкой в UI, то почему бы не называть ветки так:
release/1.0/road
release/2.0/road
release/3.0/road
Смысл 'road' (имя от балды, можно и, к примеру, head) в том, чтобы обеспечить возможность создания подветок:
release/1.0/0/road
release/1.0/1/road
или еще более замысловатые:
release/1.0/1/01.00/road
это если в четвертой части идет кодирование версии модуля продукта.
Третий вопрос
Подбешивают списки вида:
И, думаю, не меня одного.
Тем не менее нигде не видел, чтобы в ветках/метках с версиями использовали ведущие нули.
Ветки/метки создают гуру, которых такие мелочи не парят?
Последний вопрос
Ветки с версиями оформляют в виде "release/xxx.xxx"
А метки (теги) релизов как правило нет. В EFCore, к примеру, сначала делали метки с префиксом "release/" а потом на это забили и создают метки просто со строкой версии — "vXX.XX.XX".
Почему не прижилось?
SourceTree может группировать метки так же как и ветки.
Еле вспомнил, еще один
Метки, кроме обозначения версий релизов, еще для чего-нибудь используют?
Спасибо за ответы!
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Коваленко Дмитрий, Вы писали:
Сорри что не подробно, но возможно ты имеешь в виду "release branches"?
К SourceTree или GUI они не имеют отношения. Также в них (обычно) не разрабатывают.
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow (пролистать до "release branches")
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Привет тем, у кого уже утро понедельника
КД>Первый вопрос
КД>Во многих репозиториях вижу ветки:
КД>release/1.0
КД>release/2.0
КД>release/3.0
КД>Это как-то связано с тем, что SourceTree такие ветки группирует?
КД>Или это не только SourceTree такое может делать?
Это SourceTree, наверно, группирует потому, что так удобно делать.
КД>Второй вопрос
КД>Если такая стратегия именования действительно связана с группировкой в UI, то почему бы не называть ветки так:
КД>release/1.0/road
КД>release/2.0/road
КД>release/3.0/road
КД>Смысл 'road' (имя от балды, можно и, к примеру, head) в том, чтобы обеспечить возможность создания подветок:
А чем это отличается от ситуации в любой файловой системе, если, например, создаёте файл abc и хотите к нему создать каталог и файлы abc/def, abc/xyz?
Я вот на днях зачекаутил софтину в, грубо говоря, foo, а потом решил, что мне нужны foo/foo она сама, foo/build для сборки, foo/build.log для лога сборки...
А создать просто так foo нельзя уже. Пришлось переименовывать — примерно так:
mkdir foo.d
mv foo foo.d
mv foo.d foo
гимор, а что делать?
КД>release/1.0/0/road
КД>release/1.0/1/road
КД>или еще более замысловатые:
КД>release/1.0/1/01.00/road
Можно. Если вы думаете, что это вам нужно — создавайте. Кто запрещает-то?
Вообще, да, достаточно логично — если ставить такую задачу.
КД>это если в четвертой части идет кодирование версии модуля продукта.
КД>Третий вопрос
КД>Подбешивают списки вида:
КД>
КД>1.0
КД>10.0
КД>2.0
КД>3.0
КД>4.0
КД>
КД>И, думаю, не меня одного.
КД>Тем не менее нигде не видел, чтобы в ветках/метках с версиями использовали ведущие нули.
КД>Ветки/метки создают гуру, которых такие мелочи не парят?
А до какого уровня нужно заранее генерировать эти ведущие нули? Вам достаточно 3 цифр, или надо 4?
Как для меня лично — чуть-чуть парят, конечно. Но не сильно. Просто когда понимаешь, что заранее на всех не напасёшься...
Вон Microsoft, по слухам, пропустила Windows 9, потому что много народа матчили 9* как 95 и 98.
Сейчас можно, конечно, просто годами называть (версия 2021 или просто 21, как у Oracle). Но это не дружит, конечно, с semantic versioning.
Кстати, как раз читаю из определения semantic versioning:
2. A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0.
То есть не просто нежелательно подставлять нули, а явно запрещено.
Можно, конечно, попросить все подобные тулзы действовать как раз по правилам этих сравнений — если имя версии выглядит как version number, сравнивать соответственно (для одного компонента — будет просто как натуральные числа). Может, надо породить тикеты для вашей любимой тулзы делать сравнения именно так.
