| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
Instead of relying on setup.py, use setup.cfg.
Dev/doc requirements have been moved there as well, under the `doc` and
`dev` extras.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Including docs and tests.
Closes #98.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
A leading zero is forbidden in the SemVer spec, but could be valid under
other schemes; when coercing, it can easily be removed.
Closes #89, thanks to Andrew Ni for the report.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Thanks to Nathan Walters for spotting this.
Npm ranges with a `<X.Y.Z-P` component were not properly expanded:
they were converted to:
<X.Y.0 || (>=X.Y.0 && <X.Y.Z-P && no-prerelease)
The correct expansion is:
<X.Y.0 || (>=X.Y.0-* && <X.Y.Z-P)
Closes #86.
|
| |
|
|
|
|
|
|
| |
This function allows developers to preview the structure of the
resulting clause parsed from a spec, usable with
`print(spec.clause.prettyprint())`.
Apply typical PEP8 indentation rules.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This (deprecated) property failed when used on a `Spec` item based on a
single-term range (e.g. `==0.1.2` `<2.0.0`).
Closes #82.
|
| |
|
|
| |
Signed-off-by: Raphaël Barrois <raphael.barrois@polytechnique.org>
|
| | |
|
| | |
|
| |
|
|
| |
This attribute wasn't meant to be removed.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Their comparison semantics were ill-defined, and mostly an
implementation detail for the old, 'native' specs.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
| |
Avoids generating text to be parsed immediately.
|
| |
|
|
|
|
| |
Eases the creation of version objects from existing versions.
We still validate the type and structure of each component.
|
| |
|
|
|
| |
Do this so any subclasses will be shown with their class name instead of
a potentially misleading Version
|
| |
|
|
| |
Drop compatibility layer for Django<1.11.
|
| |
|
|
|
|
| |
Closes #65.
Reported-By: Julian Berman <julian@grayvines.com>
|
| | |
|
| | |
|
| |
|
|
| |
Update tests accordingly.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Stop coercing fields magically:
>>> a = SomeModel()
>>> a.version = '0.1.0'
>>> a.version
'0.1.0'
>>> a.full_clean()
>>> a.version
Version('0.1.0')
Closes #43, #45
|
| |
|
|
|
| |
Previously, if the patch version was 0 (i.e. as in ~=2.2.0),
this would cause the range to be interpreted as ~=2.2.
|
| | |
|
| |
|
|
| |
Thanks to @autopulated for pointing the issue!
|
| | |
|
