Как должны быть связаны версии программных пакетов?

Question

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

Примеры в Java:

• org.springframework
• com.fasterxml.jackson
• org.hamcrest

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

Преимущества, которые я вижу, заключаются в том, что:

• Пользователи могут использовать одну версию для мониторинга и обновления
• Вероятно, все пользователииспользовать одну и ту же комбинацию библиотек

Недостатки:

• Пользователи, использующие только одну из множества библиотек, могут получать уведомления об «обновлении», хотя загружаемый пакет не имеетизменено
• Если многие пользователи используют только подпакет, то все отчеты об ошибках для одной версии в равной степени относятся к ряду версий, которые трудно отследить.Возврат к предыдущей «другой» версии, чтобы избежать ошибки, становится более сложным.

Answer 1

Одной из альтернатив одиночному версионированию является использование спецификации (ведомости материалов).Существуют различные концепции спецификаций:

• Спецификация может перечислить несколько зависимостей для включения в свои версии (например, метапакеты Linux apt )
• Спецификация может определятьверсии (и другие ограничения) для зависимостей, которые будут использоваться, если зависимость включена (например, Java Maven dependencyManagement раздел спецификации)

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

Не все системы распространения программного обеспечения и сборки одинаково хорошо поддерживают концепцию спецификации,хотя.