4-значное управление версиями в npm

Question

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

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

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

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

Answer 1

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

Например. ваша версия будет выглядеть 1.1.1-1.

Я видел в нем другие проекты для альфа-версий и т. Д., И он также допускает нестандартные номера версий. Несколько примеров из npm:

• vue-class-component@8.0.0-rc.1
• react-docgen@3.0.0-beta7

Однако имейте в виду, что при использовании любого из npm version major / minor / patchкоманды, это число сначала не будет увеличиваться, а просто обрезать все, начиная с первого -персонаж. Пример:

1.0.6-1

1.0.6

npm version patch

1.0.7

Я думаю, это связано с тем, что обычно люди используют его, чтобы пометить версию, которая будет включена. alpha / beta / rcв этом порядке, и когда версия является окончательной, вы сохраняете номер версии, но удаляете суффикс.

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

Answer 2

Прямой ответ на ваш вопрос квалифицированный да. Некоторые полуверы, поддерживающие пакет / инструменты управления версиями, допускают строки с четырьмя числовыми версиями, но они не могут анализировать их в полях и должны использовать сравнение строк или выдавать ошибку при сравнении, что обычно не требуется при сравнении строк версии. Другими словами, вы теряете семантику, которая должна быть закодирована в четырех полях версии. (См. Тему Принуждения для описания поведения 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 к версии.

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