lsm/initializr
1
0
Fork 0
mirror of https://gitee.com/dcren/initializr.git synced 2026-02-25 21:22:58 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity

Document version format support

Browse Source 
See gh-1092
This commit is contained in:
Stephane Nicoll
2020-06-03 10:58:54 +02:00
parent 853ee51f2b
commit b3f5ca9aab
1 changed files with 45 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

56
initializr-docs/src/main/asciidoc/configuration-guide.adoc
View File

@@ -542,21 +542,30 @@ it. The versions are *not* applied to the dependency itself, but rather used to
the dependency, or modify it, when different versions of Spring Boot are selected for the the dependency, or modify it, when different versions of Spring Boot are selected for the
generated project. generated project.
A typical version is composed of four parts: a major revision, a minor revision, a patch A version is composed of four parts: a major revision, a minor revision, a patch
revision and a qualifier. Qualifiers are ordered as follows: revision and an optional qualifier. Spring Initializr supports two version formats:
* `V1` is the original format where the qualifier is separated from the version by a dot.
It also uses well-defined qualifiers for snapshots (`BUILD-SNAPSHOT`) and General
Availability (`RELEASE`).
* `V2` is an improved format that is SemVer compliant, and therefore uses a dash to
separate the qualifier. There is no qualifier for GAs.
Speaking of qualifiers, they are ordered as follows:
* `M` for milestones (e.g. `2.0.0.M1` is the first milestone of the upcoming 2.0.0 * `M` for milestones (e.g. `2.0.0.M1` is the first milestone of the upcoming 2.0.0
release): can be seen as "beta" release release): can be seen as "beta" release
* `RC` for release candidates (e.g. `2.0.0.RC2` is the second release candidate of * `RC` for release candidates (e.g. `2.0.0-RC2` is the second release candidate of
upcoming 2.0.0 release) upcoming 2.0.0 release)
* `RELEASE` for general availability (e.g. `2.0.0.RELEASE` is 2.0.0 proper)
* `BUILD-SNAPSHOT` for development build (`2.1.0.BUILD-SNAPSHOT` represents the latest * `BUILD-SNAPSHOT` for development build (`2.1.0.BUILD-SNAPSHOT` represents the latest
available development build of the upcoming 2.1.0 release). available development build of the upcoming 2.1.0 release). For the `V2` format, it is
simply `SNAPSHOT`, i.e. `2.1.0-SNAPSHOT`.
TIP: snapshots are in a bit special in that scheme as they always represents the "latest * `RELEASE` for general availability (e.g. `2.0.0.RELEASE` is 2.0.0 proper)
state" of a release. `M1` represents the most oldest version for a given major, minor and
patch revisions.
TIP: snapshots are in a bit special in that scheme as they always represent the "latest
state" of a release. `M1` represents the oldest version for a given major, minor and
patch revisions, and it can therefore be safely used when referring to the "first" release
in that line.
A version range has a lower and an upper bound, and if the bound is inclusive it is A version range has a lower and an upper bound, and if the bound is inclusive it is
denoted as a square bracket (`[` or `]`), otherwise it is exclusive and denoted by a denoted as a square bracket (`[` or `]`), otherwise it is exclusive and denoted by a
@@ -572,7 +581,7 @@ an hard-coded version. For instance, `1.4.x.BUILD-SNAPSHOT` is the latest snapsh
of the 1.4.x line. For instance, if you want to restrict a dependency from `1.1.0.RELEASE` of the 1.4.x line. For instance, if you want to restrict a dependency from `1.1.0.RELEASE`
to the latest stable release of the 1.3.x line, you'd use `[1.1.0.RELEASE,1.3.x.RELEASE]`. to the latest stable release of the 1.3.x line, you'd use `[1.1.0.RELEASE,1.3.x.RELEASE]`.
Snapshots are naturally ordered higher than released versions, so if you are looking to Snapshots are naturally the most recent version of a given line, so if you are looking to
match a dependency to only the latest snapshots of Spring Boot, you could use a version match a dependency to only the latest snapshots of Spring Boot, you could use a version
range of `1.5.x.BUILD-SNAPSHOT` (assuming 1.5 was the latest). range of `1.5.x.BUILD-SNAPSHOT` (assuming 1.5 was the latest).
@@ -580,7 +589,8 @@ TIP: Remember to quote the values of a version range in YAML configuration files
double quotes ""). double quotes "").
See below in the section on <<howto-link-boot-version,linking versions>> for more examples See below in the section on <<howto-link-boot-version,linking versions>> for more examples
and idioms. and idioms. See also how the <<howto-platform-version-format,platform version format>> can
be configured.
@@ -1017,6 +1027,30 @@ These dependencies, by default, will be available only for Spring Boot versions
[[howto-platform-version-format]]
=== Configure platform version format
Spring Initializr supports two formats: `V1` is the original format defined by metadata
up to `2.1`. `V2` is the SemVer format provided alongside `V1` as of metadata `2.2`. In
order to serve backward compatible content, the version range for each format should be
configured so that translations can happen accordingly.
Let's assume that an instance only supports `2.0.0` and later and the platform version is
using the original format up to `2.4.0` (excluded). As of `2.4.0`, the improved, SemVer
format is used. The following configures the instance to adapt version format
automatically:
[source,yaml,indent=0]
----
initializr:
env:
platform:
compatibility-range: "2.0.0.RELEASE"
v1-format-compatibility-range: "[2.0.0.RELEASE,2.4.0-M1)"
v2-format-compatibility-range: "2.4.0-M1"
----
[[create-instance-advanced-config]] [[create-instance-advanced-config]]
== Advanced configuration == Advanced configuration