4-значное управление версиями в npm - PullRequest
0 голосов
/ 16 ноября 2018

Я удивлен, что 4-значное управление версиями не разрешено в экосистеме npm:

https://docs.npmjs.com/about-semantic-versioning

enter image description here

Однако,Я должен объединить мой конечный продукт из npm в другие системы, где разрешено 4 цифры.Итак, мой вопрос:

(как) мы можем как-то сделать исключение для наших собственных проектов, использующих 4 цифры?

1 Ответ

0 голосов
/ 17 ноября 2018

Прямой ответ на ваш вопрос квалифицированный да. Некоторые полуверы, поддерживающие пакет / инструменты управления версиями, допускают строки с четырьмя числовыми версиями, но они не могут анализировать их в полях и должны использовать сравнение строк или выдавать ошибку при сравнении, что обычно не требуется при сравнении строк версии. Другими словами, вы теряете семантику, которая должна быть закодирована в четырех полях версии. (См. Тему Принуждения для описания поведения NPM в этом случае )

Преобразования могут быть возможны, но, как правило, их трудно получить правильно:

Семантика различных схем версий полей 1, 2, 3, 4, ... n меняется, даже когда количество полей совпадает. Там, где есть строка версии, такая как «1.1.1», которая корректно переводится в другую схему как «1.1.1», семантика двух схем одинакова, или «1.1.1» является особым случаем. Там, где количество полей варьируется, возможно, что набор полей меньшей схемы может быть расположен с фиксированным смещением в пределах полей более крупных схем (с постоянными значениями для остальных полей). Также может быть возможно извлечь подмножество больших полей схем, чтобы перенести их в меньшие поля схем. В любом случае невозможно иметь одну строку версии, которая работает как в схеме большего, так и меньшего размера, не нарушая семантику одной или обеих схем.

Перевод из одной схемы в другую требует глубокого понимания семантики обеих схем. Многие из четырехзначных схем являются, по сути, полумесяцами с дополнительным счетчиком сборки:

X.Y.Z.B
X is major or breaking changes.
Y is minor or non-breaking feature changes.
Z is patch or non-breaking changes that do not add features.
B counts from zero after the last X/Y/Z change.

Перевод из такой схемы в semver невозможен без всей истории выпуска из X'.Y'.Z'.0 - X'.Y'.Z'.n и некоторых средств обнаружения новых функций и разрывов сборки между любыми n и n+1. В таких случаях, как Nuget / .NET, вы можете заблокировать поле B до нуля и применить semver к оставшимся полям, тогда перевод из Neget / .Net включает удаление дополнительного поля, а из semver подразумевается добавление .0 к версии.

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

...