Changes between Version 12 and Version 13 of Obsolete/MovedToTree/PackageManagement/BuildingPackages

Timestamp:

Apr 18, 2013, 4:42:37 PM (12 years ago)

Author:

bonefish

Comment:

Pre-release separator -> "~"; allow '.' in a few components

Obsolete/MovedToTree/PackageManagement/BuildingPackages

@@ -35 +35 @@
 
 The supported attributes are:
- * `name`: The name of the package, not including the package version. Must only contain `<alphanum_underline>` characters.
+ * `name`: The name of the package, not including the package version. Must only contain `<alphanum_underline_dot>` characters.
  * `version`: The version of the package. The string must have the `version` format (see the [wiki:PackageManagement/BuildingPackages#VersionStrings Version Strings] section).
  * `architecture`: The system architecture the package has been built for. Can be either of:
@@ -55 +55 @@
 {{{
 entity          ::= entity_name [ "=" version_ref ] [ ( "compat" | "compatible" ) ">=" version_ref ]
-entity_name     ::= [ entity_type ":" ] alphanum_underline+
+entity_name     ::= [ entity_type ":" ] alphanum_underline_dot+
 entity_type     ::= "lib" | "cmd" | "app" | "add_on"
 }}}
@@ -77 +77 @@
 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 "]" ] "-" revision
-version_ref     ::= major [ "." minor [ "." micro ] ] [ "[" pre_release "]" ] [ "-" revision ]
+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     ::= alphanum_underline+
+micro           ::= alphanum_underline_dot+
+pre_release     ::= alphanum_underline_dot+
 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.
 
-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 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 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.