Семантическое управление версиями и зависимости

Question

Некоторый контекст: я работаю в команде, которая производит 6 различных пакетов NuGet, которые напрямую, а иногда и косвенно, зависят друг от друга.Просто у нас может быть такая ситуация, как p0 < p1 < p2, где пакет p0 зависит от p1, что, в свою очередь, зависит от p2.Мы пытаемся следовать семантическому версионированию для этих пакетов, но не совсем уверены, что делать с версией p0 при изменении p1 или p2.

Вот несколько конкретных примеров:

• p1 вносит критические изменения (скажем, 0.0.0 → 1.0.0).Мы хотим опубликовать версию p0, которая зависит от 1.0.0.Должно ли это быть основным или второстепенным выпуском версии для p0?
• p1 вносит незначительные изменения (0.0.0 → 0.1.0).Должно ли это сделать незначительную версию исправления для p0?

Что более важно,

Существуют ли какие-либо стандарты / консенсус относительно того, как изменения версии зависимости должны влиять на версию пакетаизменения?

Answer 1

Ни в коем случае не предполагая, что отличный ответ @ BradleyDotNET является недостаточным.Я просто хочу добавить свой взгляд на это.

p1 вносит решающее изменение (скажем, 0.0.0 → 1.0.0).Мы хотим опубликовать версию p0, которая зависит от 1.0.0.Должно ли это быть основным или второстепенным выпуском версии для p0?

Да, вы вносите критическое изменение в пользователей p0.

p1 вносит незначительные изменения (0.0.0 → 0.1.0).Должно ли это сделать незначительную версию / версию патча для p0?

Если дополнительный интерфейс от p1 открыт в интерфейсе p0, то второстепенный.Если зависимость находится на уровне реализации, то исправьте.Реальный вопрос здесь заключается в том, почему вы принимаете это изменение зависимости?Если это добавить интерфейс к публичной поверхности p0, то это незначительный удар для p0, в противном случае это удар уровня патча.

Еще одна вещь, которую следует рассмотреть здесь, это то, к чему именно вы применяете номера версий.Пакеты, библиотеки и интерфейсы - это разные вещи, и все они могут быть независимо от версии.Как указывает BradleyDotNET, некоторые пакеты содержат коллекции независимо версионных артефактов.Возможно, вы захотите изменить свою стратегию так, чтобы ваши интерфейсы могли иметь стабильные версии, несмотря на частую переупаковку.

Answer 2

Семантическое управление версиями - это все, что означает изменение для пользователей этой библиотеки .Так что, если изменение в p1 не приведет к серьезному изменению в p0, тогда я не понимаю, почему это потребовало бы увеличения основной версии в p0.

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

Предупреждение, контент, основанный на мненияхforward

На мой взгляд, есть немало «предостережения об уплате», если вы непосредственно используете транзитивную зависимость (то есть, используете p1, но только перечислите p0 в качестве зависимости) в качествеклиент библиотеки.Это удваивается, когда у вас есть много зависимостей (как в большинстве пакетов NPM), которые проходят много-много уровней вниз.Я не ожидаю, что авторы этих библиотек будут отслеживать все изменения версий всех транзитивных зависимостей, поэтому я знаю, что нужно проверить.