Skip to main content

Конференции

Просмотр конференции fido7.ru.ftrack:

Предыдущее Следующее

Дата: 03 Feb 2020, 15:01:10
От: Semen Panevin @ 2:5025/121.0
Кому: Michael Dukelsky
Тема: Re: Новая версия RNtrack 2.0.3


    Доброго здоровьица тебе, Michael!

 Monday February 03 2020 11:48, Michael Dukelsky писал Semen Panevin:

 SP>> Где заканчивается 2.0.4 и начинается 2.0.5?

 MD> ОК, я тебя понял. Давай сделаем так. Начиная с версии 2.0.4 номер
 MD> патча будет увеличиваться на 1 при каждом коммите. Версии 2.0.4
 MD> соответствовала ревизия 269. Будем считать, что после 2.0.4 во всех
 MD> 2.0.Х номер патча равен номеру ревизии минус 269. Когда появится 2.1.0
 MD> то во всех 2.1.Х номером патча будет номер текущей ревизии минус номер
 MD> ревизии версии 2.1.0. В данный момент, когда я это пишу, номер ревизии
 MD> 279, значит версия 2.0.14. При следующем коммите будет 280 и 2.0.15.
 MD> Практически это означает что и мне, и тебе коммитить надо не командой
 MD> svn ci, а скриптом, который сначала увеличивает номер патча в файлах
 MD> hpp/constant.hpp и MakeFiles/linux/rntrack.spec
Тут всё немножко сложнее. В ChangeLog присутствует номер ревизии, привязанный к номеру версии. Если он вписывается в ChangeLog не тем же скриптом, то легко ошибиться, неправильно спрогнозировав номер
ревизии перед коммитом, потому что коммитишь не один ты.

Надо подумать над более простой схемой версионирования. Я попытаюсь предложить что-то дельное.

Опять же, можно допустить что номер патча имеет смысл только при выпуске новой версии (что подразумевает собой или тэгирование, или выкладывание архива исходников, соответствующего определённой
ревизии).

Возможно стоит схему упростить, превратить в Major.Minor.Rev где Rev всегда будет соответствовать номеру ревизии, при билде из svn его можно автоматически подставлять в defines/variables, а при
выпуске архива с исходниками хардкодить текущую ревизию. А Major.Minor изменять руками при наличии правок связанных с изменением бинарей (при любом из возможных сочетаний опций билда).

В таком случае будет относительно просто выпускать новую версию в которой изменится только Rev если например там были важные правки в документации и мы хотим выпустить новую версию _пакета_ но
обозначить что функциональных правок там нет, и легко отличать наличие функциональных правок в новом пакете по различию Minor.Major с предыдущим.

Или можно оставить всё как есть, но договориться что увеличение номера версии в исходниках != выпуску этой версии, а выпуск новой версии (сопровождаемый ОДНОЙ записью в ChangeLog содержащей суммарную
инфу по правкам с момента последней выпущенной версии) обязательно сопровождается выкладыванием архива с исходниками, соответствующего данной версии, и опционально - собранными бинарными пакетами для
одной или нескольких поддерживаемых систем.

Мне кажется, такой опыт больше всего похож на общепринятый.

                                С наилучшими пожеланиями, Семён.

... Если человек родился, то это уж на всю жизнь... (c)...

--- GoldED+/LNX 1.1.5-b20180707 (Linux 4.1.12-gentoo iF6M10)
Origin: IceLAN (2:5025/121)

Предыдущее Следующее

К списку сообщений
К списку конференций