У нас есть несколько внутренних пакетов - как Nuget, так и NPM - которые мы используем в ряде внутренних приложений.Все эти пакеты рассматриваются как своего рода бета / ранний доступ - нет формальных требований и т. Д., И изменения вносятся в каждом конкретном случае.
С чем мы боремся, так это версионированием.Насколько я понимаю, по крайней мере для пакетов NPM номера версий должны быть major.minor.patch или Break-changes.new-features.bug-fixes.
Мы обнаруживаем, что существуеттенденция вносить критические изменения в пакеты и просто увеличивать пакет исправлений, что приводит к путанице.Одним из аргументов является то, что мы должны увеличивать основную версию каждый раз, когда у нас происходят серьезные изменения.Другим аргументом является то, что, поскольку мы до версии 1.0, ожидаются критические изменения, поэтому приращения патча / минорной версии вполне приемлемы.
Последнее осложнение заключается в том, что некоторые из этих пакетов зависят от других пакетов,скажем, угловой.При обновлении до более поздних версий Angular мы обнаруживаем, что еще больше боремся с управлением версиями, поскольку есть желание выровнять приращения версий Angular, но при этом поддерживать возможность увеличения основных версий для прерывания изменений.В настоящее время мы обсуждаем переход на angular-version.breaking-changes.nonbreaking изменения способ управления версиями наших пакетов.
Любопытно услышать некоторые мысли о семантическом версионировании от любого, кто думает, что он понял это правильно,Как ты делаешь это?Когда вы переходите от -beta до 1.0?Используете ли вы майор / минор / патч версионирование по назначению?