1. Обзор
Обычно при именовании версий выпуска используется семантическое управление версиями . Например, эти правила применяются к такому формату версии, как MAJOR.MINOR.REVISION :
- ОСНОВНЫЕ: Основные функции и потенциальные критические изменения
- НЕБОЛЬШИЕ: функции обратной совместимости
- ПЕРЕСМОТР : Исправления и улучшения, совместимые с предыдущими версиями .
Наряду с семантическим управлением версиями в проектах часто используются метки для дальнейшего уточнения состояния конкретного выпуска. Фактически, используя эти метки, мы даем подсказки о жизненном цикле сборки или о том, где публикуются артефакты.
В этой быстрой статье мы рассмотрим схемы именования версий, принятые в основных проектах Spring.
2. Spring Framework и Spring Boot
В дополнение к Semantic Versioning мы видим, что Spring Framework и Spring Boot используют эти метки:
- ПОСТРОЙКА-СНИМОК
- М[
число] - RC[
номер] - ВЫПУСКАТЬ
BUILD-SNAPSHOT — это текущая разрабатываемая версия. Команда Spring создает этот артефакт каждый день и развертывает его на https://repo.spring.io/ui/native/snapshot .
Выпуск Milestone (M1, M2, M3, …) знаменует собой важный этап в процессе выпуска. Команда создает этот артефакт после завершения итерации разработки и развертывает его на https://repo.spring.io/ui/native/milestone .
Релиз-кандидат (RC1, RC2, RC3, …) — это последний шаг перед созданием окончательного релиза. Чтобы свести к минимуму изменения кода, на этом этапе должны выполняться только исправления ошибок. Он также развернут на https://repo.spring.io/ui/native/milestone .
В самом конце процесса выпуска команда Spring выпускает RELEASE. Следовательно, это обычно единственный готовый к производству артефакт. Мы также можем называть этот выпуск общедоступным .
Эти метки расположены в алфавитном порядке , чтобы убедиться, что менеджеры сборки и зависимостей правильно определяют, является ли версия более новой, чем другая. Например, Maven 2 ошибочно считал версию 1.0-SNAPSHOT более новой, чем версию 1.0-RELEASE. Maven 3 исправил это поведение. Как следствие, мы можем испытывать странное поведение, когда наша схема именования не оптимальна.
3. Зонтичные проекты
Зонтичные проекты, такие как Spring Cloud и Spring Data, представляют собой проекты над независимыми, но связанными подпроектами. Чтобы избежать конфликтов с этими подпроектами, зонтичный проект использует другую схему именования. Вместо пронумерованной версии каждая версия Release Train имеет специальное имя.
В алфавитном порядке станции лондонского метро послужили источником вдохновения для названий выпусков Spring Cloud — для начала, Angel, Brixton, Finchley, Greenwich и Hoxton.
В дополнение к меткам Spring, показанным выше, он также определяет метку Service Release (SR1, SR2…) . Если мы обнаружим критическую ошибку, может быть выпущен Service Release.
Важно понимать, что выпуск Spring Cloud совместим только с определенной версией Spring Boot. В качестве справки, страница Spring Cloud Project содержит таблицу совместимости.
4. Вывод
Как показано выше, важно иметь четкую схему именования версий. Хотя некоторые выпуски, такие как Milestones или Release Candidates, могут быть стабильными, мы всегда должны использовать готовые к работе артефакты. Какова ваша схема именования? Какие у него преимущества перед этим?