| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
Using `make update` is closer to common patterns than `make
install-deps`; it is also suitable to update the local development
environment.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
|
|
|
| |
This provides more helpful error messages when a test fails.
|
| |
|
|
|
|
| |
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 I am available as a reference for questions about the changes I
have made
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
Django: Support the latest released version, and the latest LTS before
that version.
Python: Add support for python3.6 and pypy3.
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Closes #65.
Reported-By: Julian Berman <julian@grayvines.com>
|
| |
|
| |
|
|
|
|
|
| |
Pypy seems to deconstruct fields differently from Django, thus bringing
in variations in the actual deconstruct() output.
|
| |
|
|
|
|
| |
Update tests accordingly.
|
| |
|
|
|
|
|
| |
* Use tox
* Add a full linting step
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|\
| |
| | |
Convert readthedocs links for their .org -> .io migration for hosted projects
|
|/
|
|
|
|
|
|
| |
As per [their blog post of the 27th April](https://blog.readthedocs.com/securing-subdomains/) ‘Securing subdomains’:
> Starting today, Read the Docs will start hosting projects from subdomains on the domain readthedocs.io, instead of on readthedocs.org. This change addresses some security concerns around site cookies while hosting user generated data on the same domain as our dashboard.
Test Plan: Manually visited all the links I’ve modified.
|
|\
| |
| | |
Add a doc section about compatible release clauses
|
| |
| |
| |
| |
| | |
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.
|
|/ |
|
|\
| |
| | |
Add support for compatible release ranges
|
| | |
|
|/ |
|
|
|
|
| |
Thanks to @autopulated for pointing the issue!
|
| |
|
| |
|
| |
|
|
|
|
| |
Drop support for Django 1.4; go up to 1.9
|
| |
|
|
|
|
| |
The PR was broken through fixed in ``next_minor()`` / ``next_major()``.
|
|\ |
|