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


Ignore:
Timestamp:
Apr 15, 2013, 6:16:30 PM (7 years ago)
Author:
bonefish
Comment:

release -> revision

Legend:

Unmodified
Added
Removed
Modified
  • Obsolete/MovedToTree/PackageManagement/BuildingPackages

    v10 v11  
    7575=== Version Strings ===
    7676
    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 release component (`version`), while the latter two don't (`version_ref`):
     77Versions 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`):
    7878{{{
    79 version         ::= major [ "." minor [ "." micro ] ] [ "-" pre_release ] "-" release
    80 version_ref     ::= major [ "." minor [ "." micro ] ] [ "-" pre_release ] [ "-" release ]
     79version         ::= major [ "." minor [ "." micro ] ] [ "-" pre_release ] "-" revision
     80version_ref     ::= major [ "." minor [ "." micro ] ] [ "-" pre_release ] [ "-" revision ]
    8181major           ::= alphanum_underline+
    8282minor           ::= alphanum_underline+
    8383micro           ::= alphanum_underline+
    8484pre_release     ::= alpha_underline alphanum_underline*
    85 release         ::= integer_between_0_and_99
     85revision        ::= positive_non_zero_integer
    8686}}}
    8787The 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.
     
    8989The 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).
    9090
    91 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.
     91The 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.
    9292
    9393