Изменение версии в пакетах OSGi

Я думаю о лучшем способе управления версиями в нашем проекте. На данный момент каждый пакет в наших пакетах экспортируется (это будет улучшено позже, так что не зацикливайтесь на этой оплошности). Мы используем плагин maven-bundle-plugin, который либо берет версию package из файла packageinfo, либо, если файлов нет, из версии пакета (т. е. pom версия).

Итак, мой вопрос: кажется, что наличие packageinfo для каждого пакета - это много (опять же, я знаю, что сокращение экспортируемых пакетов исправляет это), поэтому мне интересно, почему лучше иметь версию для каждого пакета в отличие от глобальной версии (bundle-версии)?

Итак, скажем, пакет A выпущен

 A (1.0.0)
 |...foo (1.0.0)
 |...bar (1.0.0)

теперь, если панель пакета изменится, идеальным способом выпуска пакета A будет

 A (1.0.1)
 |...foo (1.0.0)
 |...bar(1.0.1)

Было бы так плохо (если да, то почему?) иметь единую версию, чтобы foo выпускалась как 1.0.1, даже если ее содержимое не изменилось? потому что помимо наличия файла packageinfo в каждом экспортируемом пакете, разработчикам также нужно помнить об обновлении версии (и они забудут об этом), в то время как версия пакета автоматически обновляется командой maven-release-. плагин. Обратите внимание, я не говорю об использовании require-bundle. я по-прежнему хочу использовать import-package, чтобы иметь детализацию, которую он обеспечивает, и иметь возможность, при необходимости, контролировать версию пакета с помощью packageinfo, но я пытаюсь упростить рабочий процесс и запоминание разработчиков, и одна идея была оставить packageinfo только для особых случаев вместо рекомендуемого "везде"

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


versioning osgi
person Hilikus    schedule 30.01.2014    source источник
comment
Просьба уточнить. Почему опасно повторно выпускать пакет с той же версией? Если пакет на самом деле не изменился с момента вашего последнего выпуска, то он должен быть той же версии.   -  person Neil Bartlett    schedule 30.01.2014
comment
я имел в виду, что опасность состоит в том, чтобы выпустить пакет, который ИЗМЕНИЛСЯ с той же версией. сценарий заключается в том, что разработчик изменил код, но не увеличил число в packageinfo. я сравниваю последствия этого с постоянным изменением версии пакета, даже если пакет не изменился. надеюсь так понятнее   -  person Hilikus    schedule 30.01.2014

Ответы (1)


arrow_upward
2
arrow_downward

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

Теперь, как вы упомянули, есть две популярные схемы управления версиями:

  1. Версионирование всего пакета. Это означает, что каждый экспорт пакета имеет версию пакета
  2. Версионирование каждого пакета отдельно

Вариант 1 подходит, если в основном ваше собственное приложение зависит от общих пакетов. Он также популярен для библиотек, так как его легко добавить в существующие библиотеки. Главное преимущество в том, что его легко достичь. Просто позвольте плагину пакета maven использовать его значения по умолчанию. лучше всего, если пакеты, использующие общие пакеты, выпускаются вместе с пакетом, экспортирующим пакеты.

Вариант 2 хорош для API, которые используются многими слабо связанными другими приложениями. Тщательное управление версиями по пакетам гарантирует, что изменение API окажет минимальное влияние на существующих пользователей. Цена в том, что вам нужно гораздо больше внимания и усилий, чтобы хорошо управлять версиями. Так что хорошим примером для этого являются спецификации OSGi. Они достигли высокого уровня совместимости, со временем вводя новые функции.

Я могу поделиться случаем, когда версионирование по бандлу не было оптимальным. Первая предварительная версия API сервлета 3.0 экспортировала только версию пакета 3.0. Таким образом, если бы это был официальный выпуск, то каждый пакет, использующий старый API 2.5, должен был бы переключиться, поскольку диапазоны импорта по умолчанию всегда исключают следующую основную версию. В итоге новая и старая версии были экспортированы для всех совместимых пакетов. Так что это минимизировало воздействие на пользователей.

Кстати. если вы используете плагин пакета maven, то пользователю пакета не нужно много делать даже в случае управления версиями по пакету. Bnd автоматически просматривает версию каждого пакета и основывает диапазон импорта на этой информации, а не на версии пакета.

Так что в основном подумайте о влиянии на пользователей. Особенно когда делаешь новую мажорную версию. Протестируйте пользовательский пакет, скомпилированный в соответствии со старой версией вашего пакета.

person Christian Schneider    schedule 30.01.2014
comment
Я не согласен. Схема 1, как вы выразились, никогда не бывает полезной. Если вы собираетесь это сделать, то вообще не беспокойтесь о версиях пакетов, потому что назначенная вами версия ничего не значит. К сожалению, в данный момент у меня нет времени, чтобы написать полный ответ, объясняющий это, но я это сделаю. - person Neil Bartlett; 30.01.2014
comment
Схема, которую я упомянул, используется в большинстве проектов. Поэтому, хотя он и не идеален, он служит цели сделать эти проекты доступными в OSGi. Если бы вы ожидали, что они будут правильно управлять версиями на основе пакетов, у них, вероятно, вообще не было бы метаданных OSGi. - person Christian Schneider; 30.01.2014
comment
@NeilBartlett Меня интересует ваш полный ответ, чтобы объяснить, почему схема 1 никогда не бывает полезной. Пожалуйста, разместите ссылку, когда она будет доступна здесь. В настоящее время я выбираю эти две схемы, исходя из необходимости программного обеспечения. - person ceilfors; 12.02.2014