правильный порядок тегов и версий ошибок

Question

У меня есть библиотека на github, которая использует rebar, но она никогда не была помечена через git.На момент написания этой статьи файл app.src указывает, что это версия 0.1 (она никогда не менялась).

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

Какие шаги мне предпринятьсейчас и в будущем, чтобы гарантировать, что пользователи могут кодировать версию по своему выбору?

Answer 1

Я использую следующую схему в своих репозиториях:

• XYZ, где X является основным, Y является второстепенным, а Z является выпуском исправлений (некоторые идеи взяты из Semantinc Versioning )

• Порядок, в котором я изменяю файлы и теги .app.src, выглядит следующим образом:

  1. Сделайте изменение, увеличьте номер версии в файле .app.src и подтвердите его с помощьюхорошее сообщение о коммите.

  2. Тег, который фиксирует, используя тот же номер версии, что и в файле .app.src.Я ввожу сообщение тега следующей формы:

     Version X.Y.Z
     
     - New Feature 1
     - New Feature 1
     - Fix this and that
     

     Затем тег подписывается GPG с моей подписью (с использованием флага -s)

  3. Нажмите коммит с помощью git push && git push --tags для загрузки как коммита, так и тега на сервер.

Я не использую схему семантического контроля версий "vX.YZ" в качестве тегов, потому что я думаю, что это излишне ивыглядит не очень хорошо.

Если у вас есть правильные теги и версионирование (по вашему выбору), ваши пользователи смогут полагаться на использование тегов Git как есть.

Вы можете увидетьрезультаты здесь: https://github.com/eproxus/meck (вам нужно скачать код, чтобы увидеть сообщения тегов и проверить подпись GPG).