Skip to main content

Конференции

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

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

Дата: 03 Feb 2020, 20:50:56
От: Michael Dukelsky @ 2:5020/1042.0
Кому: Semen Panevin
Тема: Новая версия RNtrack 2.0.3


Привет, Semen!

03 February 2020 15:01, Semen Panevin послал(а) письмо к Michael Dukelsky:

 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. Когда
 MD>> появится 2.1.0 то во всех 2.1.Х номером патча будет номер текущей
 MD>> ревизии минус номер ревизии версии 2.1.0. В данный момент, когда
 MD>> я это пишу, номер ревизии 279, значит версия 2.0.14. При
 MD>> следующем коммите будет 280 и 2.0.15. Практически это означает
 MD>> что и мне, и тебе коммитить надо не командой svn ci, а скриптом,
 MD>> который сначала увеличивает номер патча в файлах hpp/constant.hpp
 MD>> и MakeFiles/linux/rntrack.spec
 SP> Тут всё немножко сложнее. В ChangeLog присутствует номер ревизии,
 SP> привязанный к номеру версии. Если он вписывается в ChangeLog не тем же
 SP> скриптом, то легко ошибиться, неправильно спрогнозировав номер ревизии
 SP> перед коммитом, потому что коммитишь не один ты.

Коммиты делаю не только я, но ChangeLog делаю только я при выпуске релиза. Номер версии и номер ревизии туда будет вписывать скрипт. Он не ошибётся. Текущий номер ревизии в этом скрипте легко
получить, сделав `svn up`.

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

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

Это бессмысленно, потому что номер патча становится не нужен.

 SP> Возможно стоит схему упростить, превратить в Major.Minor.Rev где Rev
 SP> всегда будет соответствовать номеру ревизии,

Это хорошая схема, но она перестанет работать при переходе на git. Её вариант, это major.minor.date, как сейчас в Husky, но мне это совсем не нравится и я хотел бы от этого уйти.

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

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

И ты не будешь спрашивать, где кончается 2.0.4 и начинается 2.0.5? :)

Желаю успехов, Semen!
За сим откланиваюсь, Michael.

... node (at) f1042 (dot) ru

--- GoldED+/LNX 1.1.5-b20170303
Origin: ==<<.f1042.ru.>>== (2:5020/1042)

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

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