Какую версию Cabal мне следует использовать для моей промежуточной ветки разработки?

У меня есть (потенциально общедоступная) ветка разработки для проекта Haskell, которую я также выпускаю для Haddock. В шапке моей релизной ветки всегда (естественно) есть файл .cabal с версией, соответствующей текущей версии Haddock.

Но какая версия должна быть в файле .cabal моей ветки разработки? Например, после выпуска версии 0.1.2.6 на Hackage никакая последующая фиксация нигде (особенно в ветке разработки) не является версией 0.1.2.6, а они (пока) не 0.1.2.7. Какой версии должны быть такие коммиты? Существует ли стандартная практика либо для Hackage в частности, либо для системы контроля версий в целом (напомним, что Cabal накладывает ограничения на значения, которые может принимать version)?


version-control cabal hackage
person orome    schedule 28.09.2015    source источник

Ответы (1)


arrow_upward
-1
arrow_downward

Я не вижу ограничительных правил для поля version

Номер версии пакета, обычно состоящий из последовательности натуральных чисел, разделенных точками.

таким образом, вы можете использовать бесплатную версию, а для Git-repos git description — хороший выбор в качестве идентификатора любого набора изменений, и эти данные можно вставить в версионный файл с помощью размазать|очистить фильтры

Примечание.

Если вам необходимо "только числовое", вы можете

  • Следуйте семантическим версиям
  • Использовать уникальную (инкрементную?) версию

но пара git describe+фильтр стала "обязательным", а не "возможным" выбором

1.0.4-14-g2414721 преобразуется в (вы, наверное, потеряли уникальную идентификацию набора изменений в случае точки ветвления между ними, но...) 1.0.4.14 и такая версия будет:

  • правильно для вас
  • может использоваться для идентификации исходного набора изменений
  • легко получить (автоматически) от git describe
person Lazy Badger    schedule 28.09.2015
comment
Извините, я не совсем понял, что имел в виду под своим ограничением: это должно быть число, то есть это не может быть что-то явно описательное, например 0.1.2.6++ или 0.1.2.6->7dev. Я полагаю, что мог бы просто использовать 0.0.0.0, но на самом деле вопрос в том, существует ли стандартная практика, особенно. на Взлом. - person orome; 29.09.2015
comment
@raxacoricofallapatorius. Стандартной практикой является широко распространенное семантическое управление версиями. Вы можете адаптировать его к вашим потребностям - person Lazy Badger; 29.09.2015
comment
Вопрос в том, какое допустимое значение указать в .cabal между выпусками Hacakge в ветке разработки. Это не может быть какая-либо предыдущая или будущая версия выпуска Hackae, и это должна быть последовательность натуральных чисел, разделенных точками. Я всегда использовал семантическую версию внутри компании, и это действительно часть вопроса: как люди адаптируют ее к Hacakge. (Этот ответ, кажется, игнорирует этот контекст.) - person orome; 29.09.2015
comment
@raxacoricofallapatorius - разве строки 1.0.4 - 1.0.4.1 - 1.0.4.2 - ... - 1.0.5 вам подходят? - person Lazy Badger; 29.09.2015
comment
Учитывая, что у меня есть, скажем, 0.1.2.6, и что следующий выпуск Hackage будет 0.1.2.7, как мне пронумеровать промежуточные версии в моем .cabal? Помните, что это должно быть собрано и установлено (с cabal install) для людей, которые загружают ветку разработки. - person orome; 29.09.2015
comment
@raxacoricofallapatorius - 0.1.2.6.* (примечание - я ничего не знаю о возможных дополнительных ограничениях сборки-установки) - person Lazy Badger; 29.09.2015
comment
Я ничего не знаю о возможных дополнительных ограничениях сборки-установки, но вот в чем вопрос! - person orome; 29.09.2015
comment
Я удалил теги, которые сбивали с толку. - person orome; 29.09.2015