| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Write clear, explicit rules for the `SimpleSpec` syntax.
|
| |
|
|
|
| |
Their comparison semantics were ill-defined, and mostly an
implementation detail for the old, 'native' specs.
|
| |
|
|
|
| |
- Use proper theme in development
- Use ReadTheDocs version numbers in titles
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This will be used in `sort(..., key=lambda v: v.precedence_key)`.
Remove previous comparison/ordering implementation.
The current implementation relies on a 4-tuple:
- major, minor, patch (as integers) - natural order matches precedence
rules
- a tuple of identifiers for the prerelease component.
The identifiers for the prerelease components are based on:
- A `NumericIdentifier` class, that compares number using their natural
order, and always compares lower than non-numeric identifiers
- A `AlphaIdentifier` class for non-numeric identifiers; it compares
versions using ASCII ordering.
- A `MaxIdentifier` class, that compares higher to any other identifier;
used to ensure that a non-prerelease version is greater than any of
its prereleases.
|
| |
|
|
|
|
|
|
|
| |
The internal features from those classes will be removed in future
versions:
- The `Spec` class is incompatible with the support of multiple syntaxes
- The `SpecItem` class was an implementation detail, but doesn't support
complex `Range` combinations.
|
| |
|
|
|
|
|
|
| |
The code follows closely the specification available at
https://docs.npmjs.com/misc/semver.html.
Despite similarities, the matching logic is fully separate from the
`native` code, since both might evolve at their own scales.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of choosing the comparison on each `.match()` call, the
expression is converted to a combination of `Range()` expressions
(simple comparison to a semver-compliant `Version`).
`Range()` objects can be combined with `And` and `Or` through the
`AnyOf` and `AllOf` clauses (sticking to Python's naming scheme).
Some specific flags have been provided to those range, allowing users to
subtly alter the matching behaviour - thus accomodating different
versioning schemes:
- `<0.1.2` won't match `0.1.2-rc1`, unless the prerelease_policy flag is
set to either `always` or `same-patch`
- `<0.1.2` will match `0.1.1-rc1`, unless the `prerelease_policy` flag
is set to `same-patch`
- `==0.1.2` will always match `0.1.2+build44`, unless the `build_policy`
is set to `strict`.
The `Spec` item has been updated, alongside `SpecItem`.
Those objects keep the original expression as attributes, but don't use
them for comparisons.
|
| | |
|
| |
|
|
|
|
|
|
| |
According to the stated goal of "intuitive" behaviour, we want:
``Version('0.1.1-a1') not in Spec('<0.1.1')``.
Tests, code and docs have been fixed.
|
| |
|
|
| |
This simplifies computing neighbouring versions.
|
| |
|
|
|
|
| |
Eases the creation of version objects from existing versions.
We still validate the type and structure of each component.
|
| |
|
|
|
|
|
|
|
|
| |
Those functions had been forgotten in the docs.
Clarify that `Version('1.0.1-alpha').next_patch()` is
`Version('1.0.1')`, since that version is the smallest non-prerelease
version greater than `Version('1.0.1-alpha')`.
Closes: #67
|
| | |
|
| |
|
|
| |
The PR was broken through fixed in ``next_minor()`` / ``next_major()``.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SemVer 2.0.0 states that "Build metadata SHOULD be ignored when
determining version precedence".
This means that, when comparing ``0.1.0+1`` to ``0.1.0+bcd``::
>>> Version('0.1.0+1') == Version('0.1.0+bcd')
False
>>> Version('0.1.0+1') != Version('0.1.0+bcd')
True
>>> Version('0.1.0+1') < Version('0.1.0+bcd')
False
>>> Version('0.1.0+1') > Version('0.1.0+bcd')
False
>>> Version('0.1.0+1') <= Version('0.1.0+bcd')
False
>>> Version('0.1.0+1') >= Version('0.1.0+bcd')
False
>>> compare(Version('0.1.0+1'), Version('0.1.0+bcd'))
NotImplemented
This change also has the following effects:
- When including build metadata in a ``Spec``, the only valid options
are ``Spec('==0.1.0+sth')`` and ``Spec('!=0.1.0+sth')``
- The meaning of ``Spec('==0.1.0+')`` is now "Only version 0.1.0 without
build metadata"
- ``Spec('==0.1.0')`` now matches ``Version('0.1.0+anything')``
|
| |
|
|
| |
Spec('*') will match all valid Version objects.
|
| | |
|
| | |
|
|
|
Also normalize the package layout.
Thanks @jdowner-gb & tleach for the report.
|
