Changes between Version 10 and Version 11 of Obsolete/MovedToTree/PackageManagement/BuildingPackages

Timestamp:

Apr 15, 2013, 6:16:30 PM (12 years ago)

Author:

bonefish

Comment:

release -> revision

Obsolete/MovedToTree/PackageManagement/BuildingPackages

@@ -75 +75 @@
 === Version Strings ===
 
-Versions strings are used in three contexts: For the package version, for resolvable versions (`provides`), and in dependency version expressions (`requires`, `supplements`, `conflicts`, `freshens`). They are structurally identical, with the exception that the former requires a release component (`version`), while the latter two don't (`version_ref`):
+Versions strings are used in three contexts: For the package version, for resolvable versions (`provides`), and in dependency version expressions (`requires`, `supplements`, `conflicts`, `freshens`). They are structurally identical, with the exception that the former requires a revision component (`version`), while the latter two don't (`version_ref`):
 {{{
-version         ::= major [ "." minor [ "." micro ] ] [ "-" pre_release ] "-" release
-version_ref     ::= major [ "." minor [ "." micro ] ] [ "-" pre_release ] [ "-" release ]
+version         ::= major [ "." minor [ "." micro ] ] [ "-" pre_release ] "-" revision
+version_ref     ::= major [ "." minor [ "." micro ] ] [ "-" pre_release ] [ "-" revision ]
 major           ::= alphanum_underline+
 minor           ::= alphanum_underline+
 micro           ::= alphanum_underline+
 pre_release     ::= alpha_underline alphanum_underline*
-release         ::= integer_between_0_and_99
+revision        ::= positive_non_zero_integer
 }}}
 The meaning of the major, minor, and micro version parts is vendor specific. A typical, but not universal (!), convention is to increment the major version when breaking binary compatibility (i.e. version a.d.e is backwards compatible to version a.b.c for all b.c <= d.e), to increment the minor version when adding new features (in a binary compatible way), and to increment the micro version for bug fix releases. There are, however, projects that use different conventions which don't imply that e.g. version 1.4 is backwards compatible with version 1.2. Which convention is used is important for the packager to know, as it is required for a correct declaration of the compatibility versions for the provided resolvables. The compatibility version specifies the oldest version the provided resolvable is backwards compatible with, thus implying the version range requested by a dependent package the resolvable can satisfy. When following the aforementioned convention a resolvable of version 2.4.3 should have compatibility version 2 (or, semantically virtually identical, 2.0.0). Not following the convention 2.4 may be correct instead. If no compatibility version is specified, the resolvable can only satisfy dependency constraints with an exactly matching version.
@@ -89 +89 @@
 The pre-release part of the version string has a special semantics for comparison. Unlike minor and micro its presence makes the version older. E.g. version R1.0-alpha1 is considered to be older than version R1.0. When both version strings have a pre-release part, that part is compared naturally after the micro part (R1.0.1-alpha1 > R1.0 > R1.0-beta1 > R1.0-alpha2).
 
-The release part of the version string is assigned by the packager (not by the vendor). It allows to uniquely identify updated packages of the same vendor version of a software.
+The revision part of the version string is assigned by the packager (not by the vendor). It allows to uniquely identify updated packages of the same vendor version of a software.