Skip to content

Commit

Permalink
Prepare for 3.0.0-rc.1 release
Browse files Browse the repository at this point in the history
* Combine all dev releases together in one changelog
* Remove all changelog.d entries and integrate it into CHANGELOG
* Move dev releases to file changelog-semver3-devel.rst
* Split contributing into different sections
* Some doc polishing; use :meth: consistently for semver.Version methods
* Fix also some doc bugs
* Amend list of contributors and sorted alphabetically by lastname
* Correct docstrings on some deprecated functions
  • Loading branch information
tomschr committed Mar 19, 2023
1 parent 467ea0c commit 45e12ec
Show file tree
Hide file tree
Showing 52 changed files with 1,039 additions and 570 deletions.
352 changes: 140 additions & 212 deletions CHANGELOG.rst

Large diffs are not rendered by default.

194 changes: 8 additions & 186 deletions CONTRIBUTING.rst
Original file line number Diff line number Diff line change
Expand Up @@ -8,6 +8,7 @@ The semver source code is managed using Git and is hosted on GitHub::
git clone git://github.com/python-semver/python-semver



Reporting Bugs and Asking Questions
-----------------------------------

Expand All @@ -34,193 +35,14 @@ consider the following general requirements:
If not, ask on its GitHub project https://github.com/semver/semver.


More topics
-----------

Modifying the Code
------------------

We recommend the following workflow:

#. Fork our project on GitHub using this link:
https://github.com/python-semver/python-semver/fork

#. Clone your forked Git repository (replace ``GITHUB_USER`` with your
account name on GitHub)::

$ git clone git@github.com:GITHUB_USER/python-semver.git

#. Create a new branch. You can name your branch whatever you like, but we
recommend to use some meaningful name. If your fix is based on a
existing GitHub issue, add also the number. Good examples would be:

* ``feature/123-improve-foo`` when implementing a new feature in issue 123
* ``bugfix/234-fix-security-bar`` a bugfixes for issue 234

Use this :command:`git` command::

$ git checkout -b feature/NAME_OF_YOUR_FEATURE

#. Work on your branch and create a pull request:

a. Write test cases and run the complete test suite, see :ref:`testsuite`
for details.

b. Write a changelog entry, see section :ref:`add-changelog`.

c. If you have implemented a new feature, document it into our
documentation to help our reader. See section :ref:`doc` for
further details.

d. Create a `pull request`_. Describe in the pull request what you did
and why. If you have open questions, ask.

#. Wait for feedback. If you receive any comments, address these.

#. After your pull request got accepted, delete your branch.


.. _testsuite:

Running the Test Suite
----------------------

We use `pytest`_ and `tox`_ to run tests against all supported Python
versions. All test dependencies are resolved automatically.

You can decide to run the complete test suite or only part of it:

* To run all tests, use::

$ tox

If you have not all Python interpreters installed on your system
it will probably give you some errors (``InterpreterNotFound``).
To avoid such errors, use::

$ tox --skip-missing-interpreters

It is possible to use one or more specific Python versions. Use the ``-e``
option and one or more abbreviations (``py37`` for Python 3.7,
``py38`` for Python 3.8 etc.)::

$ tox -e py37
$ tox -e py37,py38

To get a complete list and a short description, run::

$ tox -av

* To run only a specific test, pytest requires the syntax
``TEST_FILE::TEST_FUNCTION``.

For example, the following line tests only the function
:func:`test_immutable_major` in the file :file:`test_bump.py` for all
Python versions::

$ tox -e py37 -- tests/test_bump.py::test_should_bump_major

By default, pytest prints only a dot for each test function. To
reveal the executed test function, use the following syntax::

$ tox -- -v

You can combine the specific test function with the ``-e`` option, for
example, to limit the tests for Python 3.7 and 3.8 only::

$ tox -e py37,py38 -- tests/test_bump.py::test_should_bump_major

Our code is checked against formatting, style, type, and docstring issues
(`black`_, `flake8`_, `mypy`_, and `docformatter`_).
It is recommended to run your tests in combination with :command:`checks`,
for example::

$ tox -e checks,py37,py38


.. _doc:

Documenting semver
------------------

Documenting the features of semver is very important. It gives our developers
an overview what is possible with semver, how it "feels", and how it is
used efficiently.

.. note::

To build the documentation locally use the following command::

$ tox -e docs

The built documentation is available in :file:`docs/_build/html`.


A new feature is *not* complete if it isn't proberly documented. A good
documentation includes:

* **A docstring**

Each docstring contains a summary line, a linebreak, an optional
directive (see next item), the description of its arguments in
`Sphinx style`_, and an optional doctest.
The docstring is extracted and reused in the :ref:`api` section.
An appropriate docstring should look like this::

def to_tuple(self) -> VersionTuple:
"""
Convert the Version object to a tuple.

.. versionadded:: 2.10.0
Renamed ``VersionInfo._astuple`` to ``VersionInfo.to_tuple`` to
make this function available in the public API.

:return: a tuple with all the parts

>>> semver.Version(5, 3, 1).to_tuple()
(5, 3, 1, None, None)
"""

* **An optional directive**

If you introduce a new feature, change a function/method, or remove something,
it is a good practice to introduce Sphinx directives into the docstring.
This gives the reader an idea what version is affected by this change.

The first required argument, ``VERSION``, defines the version when this change
was introduced. You can choose from:

* ``.. versionadded:: VERSION``

Use this directive to describe a new feature.

* ``.. versionchanged:: VERSION``

Use this directive to describe when something has changed, for example,
new parameters were added, changed side effects, different return values, etc.

* ``.. deprecated:: VERSION``

Use this directive when a feature is deprecated. Describe what should
be used instead, if appropriate.


Add such a directive *after* the summary line, as shown above.

* **The documentation**

A docstring is good, but in most cases it's too dense. API documentation
cannot replace a good user documentation. Describe how
to use your new feature in our documentation. Here you can give your
readers more examples, describe it in a broader context or show
edge cases.


.. _add-changelog:

Adding a Changelog Entry
------------------------

.. include:: ../changelog.d/README.rst
:start-after: -text-begin-
* `Running the Test Suite <docs/contribute/run-test-suite.rst>`_
* `Documenting semver <docs/contribute/doc-semver.rst>`_
* `Adding a Changelog Entry <docs/contribute/add-changelog-entry.rst>`_
* `Preparing the Release <docs/contribute/release-procedure.rst>`_
* `Finish the Release <docs/contribute/finish-release.rst>`_


.. _black: https://black.rtfd.io
Expand Down
41 changes: 24 additions & 17 deletions CONTRIBUTORS
Original file line number Diff line number Diff line change
Expand Up @@ -22,30 +22,37 @@ Old maintainer:
* Kostiantyn Rybnikov <k-bx@k-bx.com>


Significant contributors
========================
List of Contributors
====================

* Alexander Puzynia <werwolf.by@gmail.com>
* Alexander Shorin <kxepal@gmail.com>
* Anton Talevnin <TalAntR@users.noreply.github.com>
* Ben Finney <ben+python@benfinney.id.au>
(in alphabetical order)

* Jelo Agnasin <jelo@icannhas.com>
* Carles Barrobés <carles@barrobes.com>
* Craig Blaszczyk <masterjakul@gmail.com>
* Damien Nadé <anvil@users.noreply.github.com>
* Eli Bishop <eli-darkly@users.noreply.github.com>
* George Sakkis <gsakkis@users.noreply.github.com>
* Jan Pieter Waagmeester <jieter@jieter.nl>
* Jelo Agnasin <jelo@icannhas.com>
* Karol Werner <karol.werner@ppkt.eu>
* Peter Bittner <django@bittner.it>
* robi-wan <robi-wan@suyu.de>
* sbrudenell <sbrudenell@users.noreply.github.com>
* Craig Blaszczyk <masterjakul@gmail.com>
* Tyler Cross <tyler@crosscollab.com>
* Dennis Felsing <def-@users.noreply.github.com>
* Ben Finney <ben+python@benfinney.id.au>
* Zane Geiger <zanecodes@users.noreply.github.com>
* T. Jameson Little <t.jameson.little@gmail.com>
* Raphael Krupinski <rafalkrupinski@users.noreply.github.com>
* Thomas Laferriere <tlaferriere@users.noreply.github.com>
* Tuure Laurinolli <tuure@laurinolli.net>
* Tyler Cross <tyler@crosscollab.com>
* Zack Lalanne <zack.lalanne@gmail.com>

* Tuure Laurinolli <tuure@laurinolli.net>
* Damien Nadé <anvil@users.noreply.github.com>
* Jan Pieter Waagmeester <jieter@jieter.nl>
* Alexander Puzynia <werwolf.by@gmail.com>
* Lexi Robinson <Lexicality@users.noreply.github.com>
* robi-wan <robi-wan@suyu.de>
* George Sakkis <gsakkis@users.noreply.github.com>
* Mike Salvatore <mssalvatore@users.noreply.github.com>
* sbrudenell <sbrudenell@users.noreply.github.com>
* Alexander Shorin <kxepal@gmail.com>
* Anton Talevnin <TalAntR@users.noreply.github.com>
* Karol Werner <karol.werner@ppkt.eu>

..
Local variables:
coding: utf-8
Expand Down
5 changes: 0 additions & 5 deletions README.rst
Original file line number Diff line number Diff line change
@@ -1,8 +1,3 @@
.. warning::

This is a development version. Do **NOT** use it
in production before the final 3.0.0 is released.

Quickstart
==========

Expand Down
5 changes: 0 additions & 5 deletions changelog.d/284.deprecation.rst

This file was deleted.

1 change: 0 additions & 1 deletion changelog.d/284.doc.rst

This file was deleted.

1 change: 0 additions & 1 deletion changelog.d/284.feature.rst

This file was deleted.

5 changes: 0 additions & 5 deletions changelog.d/344.bugfix.rst

This file was deleted.

3 changes: 0 additions & 3 deletions changelog.d/388.trivial.rst

This file was deleted.

11 changes: 0 additions & 11 deletions changelog.d/pr384.bugfix.rst

This file was deleted.

6 changes: 0 additions & 6 deletions changelog.d/pr389.trivial.rst

This file was deleted.

1 change: 0 additions & 1 deletion changelog.d/pr392.doc.rst

This file was deleted.

1 change: 0 additions & 1 deletion changelog.d/pr393.bugfix.rst

This file was deleted.

2 changes: 0 additions & 2 deletions changelog.d/pr396.bug.rst

This file was deleted.

4 changes: 2 additions & 2 deletions docs/advanced/convert-pypi-to-semver.rst
Original file line number Diff line number Diff line change
Expand Up @@ -135,7 +135,7 @@ semver:
def convert2semver(ver: packaging.version.Version) -> semver.Version:
"""Converts a PyPI version into a semver version
:param packaging.version.Version ver: the PyPI version
:param ver: the PyPI version
:return: a semver version
:raises ValueError: if epoch or post parts are used
"""
Expand All @@ -145,7 +145,7 @@ semver:
raise ValueError("Can't convert a post part to semver")
pre = None if not ver.pre else "".join([str(i) for i in ver.pre])
semver.Version(*ver.release, prerelease=pre, build=ver.dev)
return semver.Version(*ver.release, prerelease=pre, build=ver.dev)
.. _convert_semver_to_pypi:
Expand Down
5 changes: 3 additions & 2 deletions docs/advanced/create-subclasses-from-version.rst
Original file line number Diff line number Diff line change
Expand Up @@ -16,15 +16,16 @@ but the other behavior is the same, use the following code:


The derived class :class:`SemVerWithVPrefix` can be used like
the original class:
the original class. Additionally, you can pass "incomplete"
version strings like ``v2.3``:

.. code-block:: python
>>> v1 = SemVerWithVPrefix.parse("v1.2.3")
>>> assert str(v1) == "v1.2.3"
>>> print(v1)
v1.2.3
>>> v2 = SemVerWithVPrefix.parse("v2.3.4")
>>> v2 = SemVerWithVPrefix.parse("v2.3")
>>> v2 > v1
True
>>> bad = SemVerWithVPrefix.parse("1.2.4")
Expand Down
1 change: 1 addition & 0 deletions docs/advanced/index.rst
Original file line number Diff line number Diff line change
Expand Up @@ -3,6 +3,7 @@ Advanced topics


.. toctree::
:maxdepth: 1

deal-with-invalid-versions
create-subclasses-from-version
Expand Down
2 changes: 1 addition & 1 deletion docs/advanced/semverwithvprefix.py
Original file line number Diff line number Diff line change
Expand Up @@ -20,7 +20,7 @@ def parse(cls, version: str) -> "SemVerWithVPrefix":
f"{version!r}: not a valid semantic version tag. "
"Must start with 'v' or 'V'"
)
return super().parse(version[1:])
return super().parse(version[1:], optional_minor_and_patch=True)

def __str__(self) -> str:
# Reconstruct the tag
Expand Down
9 changes: 5 additions & 4 deletions docs/advanced/version-from-file.rst
Original file line number Diff line number Diff line change
Expand Up @@ -8,16 +8,17 @@ is to use the following function:

.. code-block:: python
import os
from typing import Union
from semver.version import Version
def get_version(path: str = "version") -> Version:
def get_version(path: Union[str, os.PathLike]) -> semver.Version:
"""
Construct a Version from a file
Construct a Version object from a file
:param path: A text file only containing the semantic version
:return: A :class:`Version` object containing the semantic
version from the file.
"""
with open(path,"r") as fh:
version = fh.read().strip()
version = open(path,"r").read().strip()
return Version.parse(version)
Loading

0 comments on commit 45e12ec

Please sign in to comment.