LINUX.ORG.RU

Правильное версионирование библиотек

 , ,


1

5

Пишу я shared библиотеку. Кажется другие люди начинают её потихоньку использовать да ещё добавлять в дистрибутивы, поэтому решил заморочиться стабилизацией API и правильным версионированием, чтобы при обновлении библиотеки ни у кого не возникало проблем. Напомню что библиотека устанавливается в виде libfoo.so.X.Y.Z, на неё ставятся симлинки libfoo.so и libfoo.so.X, в SONAME прописывается libfoo.so.X

Вопросы:

  • Когда нужно увеличивать X - только при поломке обратной совместимости ABI или даже при обратно совместимых изменениях? Если второе, почему и при каких условиях тогда изменяется Y?
  • Что делать с Y.Z? Почитал, понял что их трактуют кто во что горазд - кто как в semantic versioning (Y - обратно совместимые изменения ABI, Z - изменения не влияющие на ABI), кто (libtool) вообще странно, Z у него это некий age, который показывает сколько мажорных версий назад от X поддерживает библиотека (т.е. типа 5.0.2 поддерживает 5, 4, 3). Вроде бы про Y разночтений нет, поэтому думаю использовать его для совместимых изменений ABI, а Z всегда ставить в 0
  • А не стоит ли тогда вообще выкинуть Z?
  • Как часто имеет смысл обновлять версию? С релизом, или на каждый коммит, изменяющий ABI?
  • Чисто ради интереса, есть практичиская разница между вариантами когда .so ссылается на .so.X (так делает cmake) или на .so.X.Y.Z (так делают autotools)?
★★★★★

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

единственное что - если твоей библиотекой пользуется еще кто-то - четко пропиши политику формирования номеров версий в документации к своей либе и старайся эту политику не нарушать.

ananas ★★★★★ ()

Реальный пример: http://www.tedunangst.com/flak/post/OpenBSD-version-numbers

TL;DR: Например libastral.so.major.minor

  • Если в библиотеку что-то добавляется — increment minor
  • Если из библиотеки что-то убирается — incrеment major
beastie ★★★★★ ()
Последнее исправление: beastie (всего исправлений: 1)
Ответ на: комментарий от beastie

Every time a function is deleted, the major goes up by one (and minor is reset to 0). Changes are batched to prevent racing the number too much, but it’s not tied to the release number

Да, выглядит просто и адекватно. Однако хочется послушать и ГНУшников.

slovazap ★★★★★ ()

прочитай dsohowto.pf Ульриха Дреппера, автора glibc

anonymous ()

Моё имхо: X - несовместимые изменения, Y - добавление функционала, Z - исправление ошибок.

X обновлять до первого несовместимого коммита, Y и Z - по желанию, но после добавления к-л функционала/фиксов.

Чисто ради интереса, есть практичиская разница между вариантами когда .so ссылается на .so.X (так делает cmake) или на .so.X.Y.Z (так делают autotools)?

Опять имхо, всё, кроме .so.X опционально, необязательно.

backbone ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.