summaryrefslogtreecommitdiff
path: root/README.rst
Commit message (Collapse)AuthorAgeFilesLines
* Fix pip install name in READMEAlex Hogen2022-03-101-2/+2
|
* doc: Remove remaining Sphinx markup from READMERaphaël Barrois2022-02-061-3/+3
|
* docs: Update CI locationRaphaël Barrois2022-02-061-1/+1
|
* Improve documentationRaphaël Barrois2022-02-061-137/+68
| | | | | | | | | | | - The README is now a standalone document, also included as an "introduction" page; - A new "guide" section provides more details on most features; - A couple of typos were fixed. The main goal was to make the README file perfectly suitable for rendering on PyPI, while keeping its content available on the standard documentation on ReadTheDocs.
* Drop support for Travis-CIRaphaël Barrois2021-03-021-2/+2
| | | | Also replace the badge with Github Actions
* Fix mixup between 'patch' and 'build' in README.Raphaël Barrois2020-08-091-1/+1
| | | | | Thanks to Clare Macrae for catching this! Closes #104.
* Fix SimpleSpec doc in README.rst.Raphaël Barrois2020-07-081-1/+3
| | | | | | As caught by Emilio Reyes. Closes #103.
* Update README.rstThijs Damsma2019-12-211-2/+2
| | | resolves #87
* Deprecate support for 'partial' versions.rba/pre-2.8Raphaël Barrois2019-08-261-8/+0
| | | | | Their comparison semantics were ill-defined, and mostly an implementation detail for the old, 'native' specs.
* Add deprecations for Spec/SpecItem.Raphaël Barrois2019-08-261-14/+14
| | | | | | | | | 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.
* Add support for NPM-style version ranges.Raphaël Barrois2019-08-261-0/+16
| | | | | | | | 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.
* Refactor spec/version matching.Raphaël Barrois2019-08-261-35/+23
| | | | | | | | | | | | | | | | | | | | | | | 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.
* Allow Version(major=1, ...).Raphaël Barrois2019-08-241-0/+16
| | | | | | Eases the creation of version objects from existing versions. We still validate the type and structure of each component.
* Improve docs on `next_patch()`.Raphaël Barrois2018-06-181-3/+3
| | | | | | | | | | 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
* Convert readthedocs links for their .org -> .io migration for hosted projectsAdam Chainz2016-06-151-2/+2
| | | | | | | | 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.
* Test up to 3.5v2.5.0Raphaël Barrois2016-02-121-1/+15
|
* Remove Copyright years (Closes #28)Raphaël Barrois2016-02-121-1/+1
| | | | It seems that stating the copyright years is useless after all :)
* Merge pull request #26 from marcelometal/patch-1Raphaël Barrois2016-02-111-1/+1
|\ | | | | Fixed typo in README.rst
| * Fixed typo in README.rstMarcelo Jorge Vieira2015-09-111-1/+1
| | | | | | Replaced 'licence' with 'license'
* | Forbid build metadata ordering (See #18)Raphaël Barrois2015-09-151-7/+6
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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')``
* Advertise supporting Python3.4.Raphaël Barrois2015-04-011-1/+1
|
* Adds a new bump version func to the API.Rick Eyre2015-04-011-0/+16
|
* Fix README (Closes #19).Raphaël Barrois2015-04-011-6/+1
| | | | Also fixes README rendering on PyPI, hopefully.
* Update README.Raphaël Barrois2014-03-081-0/+5
|
* Add CREDITS file.Raphaël Barrois2014-03-081-11/+13
|
* Upgrade to semver-2.0.0 (Closes #3)Raphaël Barrois2014-02-131-1/+1
|
* Rename README.Raphaël Barrois2013-11-151-1/+303
| | | | Let's keep github happy...
* Initial versionRaphaël Barrois2012-05-141-0/+1
Signed-off-by: Raphaël Barrois <raphael.barrois@polyconseil.fr>