zhangyiss/spack
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

extend Version class so that 2.0 > 1.develop > 1.1 and develop > master > head > trunk > 9999 (#1983)

Browse Source 
* extend Version class so that 2.0 > 1.develop > 1.1

* add concretization tests, with preferences and preferred version.

* add master, head, trunk as develop-like versions, develop > master > head > trunk

* update documentation on version comparison
This commit is contained in:
Denis Davydov
2019-05-02 20:32:40 +02:00
committed by Greg Becker
parent 0bbd41c7f7
commit 5b82bf47af
6 changed files with 163 additions and 74 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
lib/spack/docs/packaging_guide.rst
View File

@@ -590,13 +590,15 @@ with `RPM <https://bugzilla.redhat.com/show_bug.cgi?id=50977>`_.
Spack versions may also be arbitrary non-numeric strings; any string
here will suffice; for example, ``@develop``, ``@master``, ``@local``.
The following rules determine the sort order of numeric
vs. non-numeric versions:
Versions are compared as follows. First, a version string is split into
multiple fields based on delimiters such as ``.``, ``-`` etc. Then
matching fields are compared using the rules below:
#. The non-numeric version ``@develop`` is considered greatest (newest).
#. The following develop-like strings are greater (newer) than all
numbers and are ordered as ``develop > master > head > trunk``.
#. Numeric versions are all less than ``@develop`` version, and are
sorted numerically.
#. Numbers are all less than the chosen develop-like strings above,
and are sorted numerically.
#. All other non-numeric versions are less than numeric versions, and
are sorted alphabetically.
@@ -610,7 +612,7 @@ The logic behind this sort order is two-fold:
#. The most-recent development version of a package will usually be
newer than any released numeric versions. This allows the
``develop`` version to satisfy dependencies like ``depends_on(abc,
``@develop`` version to satisfy dependencies like ``depends_on(abc,
when="@x.y.z:")``
^^^^^^^^^^^^^^^^^