kopia lustrzana https://github.com/collective/icalendar
Use proper semantic markup for files and definition list
Steve Piercy
rodzic
190ded5835
commit
8d33bcd3c7
|
|
@ -30,11 +30,11 @@ Maintainers need the following permissions.
|
||||||
Collaborators
|
Collaborators
|
||||||
-------------
|
-------------
|
||||||
|
|
||||||
Collaborators are people with write access to the repository.
|
Collaborators have write access to the repository.
|
||||||
As a collaborator, you can
|
As a collaborator, you can
|
||||||
|
|
||||||
- merge Pull Requests,
|
- merge pull requests, and
|
||||||
- initiate a new release, see below.
|
- initiate a new release.
|
||||||
|
|
||||||
We want to have as many knowledgeable people with write access taking responsibility as possible for these reasons:
|
We want to have as many knowledgeable people with write access taking responsibility as possible for these reasons:
|
||||||
|
|
||||||
|
|
@ -44,72 +44,76 @@ We want to have as many knowledgeable people with write access taking responsibi
|
||||||
- future maintainers
|
- future maintainers
|
||||||
|
|
||||||
Nobody should merge their own pull requests.
|
Nobody should merge their own pull requests.
|
||||||
If you like to review or merge pull requests of other people and you have shown that you know how to contribute,
|
If you like to review or merge pull requests of other people and you have shown that you know how to contribute, you can ask for becoming a collaborator.
|
||||||
you can ask for becoming a collaborator or a maintainer asks you if you would like to become one.
|
A maintainer may ask if you would like to become one.
|
||||||
|
|
||||||
New Releases
|
|
||||||
|
New releases
|
||||||
------------
|
------------
|
||||||
|
|
||||||
This explains how to create a new release on `PyPI <https://pypi.org/project/icalendar/>`_.
|
This section explains how to create a new release on `PyPI <https://pypi.org/project/icalendar/>`_.
|
||||||
|
|
||||||
Since collaborators and maintainers have write access the the repository, they can start the release process.
|
Since collaborators and maintainers have write access to the repository, they can start the release process.
|
||||||
However, only people with ``PyPI environment access for GitHub Actions`` can approve an automated release to PyPI.
|
However, only people with ``Environments/Configure PyPI`` access can approve an automated release to PyPI.
|
||||||
|
|
||||||
|
#. Check that the file :file:`CHANGES.rst` is up to date with the `latest merged pull requests <https://github.com/collective/icalendar/pulls?q=is%3Apr+is%3Amerged>`_, and the version you want to release is correctly named.
|
||||||
|
|
||||||
1. Check that the ``CHANGES.rst`` is up to date with the `latest merged pull requests <https://github.com/collective/icalendar/pulls?q=is%3Apr+is%3Amerged>`__
|
.. code-block:: shell
|
||||||
and the version you want to release is correctly named.
|
|
||||||
|
|
||||||
.. code-block:: bash
|
export VERSION=6.3.0
|
||||||
|
|
||||||
export VERSION=6.3.0
|
#. Create a commit on the ``release`` branch (or equivalent) to release this version.
|
||||||
|
|
||||||
2. Create a commit on the ``release`` branch (or equivalent) to release this version.
|
.. code-block:: shell
|
||||||
|
|
||||||
.. code-block:: bash
|
git checkout main
|
||||||
|
git pull
|
||||||
|
git checkout -b release main
|
||||||
|
git add CHANGES.rst
|
||||||
|
git commit -m"version $VERSION"
|
||||||
|
|
||||||
git checkout main
|
#. Push the commit and `create a pull request <https://github.com/collective/icalendar/compare?expand=1>`_.
|
||||||
git pull
|
Here is an `example pull request #457 <https://github.com/collective/icalendar/pull/457>`_.
|
||||||
git checkout -b release main
|
|
||||||
git add CHANGES.rst
|
|
||||||
git commit -m"version $VERSION"
|
|
||||||
|
|
||||||
3. Push the commit and `create a pull request <https://github.com/collective/icalendar/compare?expand=1>`__
|
.. code-block:: shell
|
||||||
Here is an `example pull request #457 <https://github.com/collective/icalendar/pull/457>`__.
|
|
||||||
|
|
||||||
.. code-block:: bash
|
git push -u origin release
|
||||||
|
|
||||||
git push -u origin release
|
#. See if the `CI-tests <https://github.com/collective/icalendar/actions>`_ are running on the pull request.
|
||||||
|
If they are not running, no new release can be issued.
|
||||||
|
If the CI passes, merge the pull request.
|
||||||
|
|
||||||
4. See if the `CI-tests <https://github.com/collective/icalendar/actions>`_ are running on the pull request.
|
#. Clean up behind you!
|
||||||
If they are not running, no new release can be issued.
|
|
||||||
If the tests are running, merge the pull request.
|
|
||||||
5. Clean up behind you!
|
|
||||||
|
|
||||||
.. code-block:: bash
|
.. code-block:: shell
|
||||||
|
|
||||||
git checkout main
|
git checkout main
|
||||||
git pull
|
git pull
|
||||||
git branch -d release
|
git branch -d release
|
||||||
git push -d origin release
|
git push -d origin release
|
||||||
|
|
||||||
6. Create a tag for the release and see if the `CI-tests`_ are running.
|
#. Create a tag for the release and see if the `CI-tests`_ are running.
|
||||||
|
|
||||||
.. code-block:: bash
|
.. code-block:: shell
|
||||||
|
|
||||||
git checkout main
|
git checkout main
|
||||||
git pull
|
git pull
|
||||||
git tag "v$VERSION"
|
git tag "v$VERSION"
|
||||||
git push upstream "v$VERSION" # could be origin or whatever reference
|
git push upstream "v$VERSION" # could be origin or whatever reference
|
||||||
|
|
||||||
7. Once the tag is pushed and its `CI-tests`_ are passing, maintainers will get an e-mail::
|
#. Once the tag is pushed and its `CI-tests`_ are passing, maintainers will get an e-mail:
|
||||||
|
|
||||||
Subject: Deployment review in collective/icalendar
|
.. code-block:: text
|
||||||
|
|
||||||
tests: PyPI is waiting for your review
|
Subject: Deployment review in collective/icalendar
|
||||||
|
|
||||||
8. If the release is approved by a maintainer. It will be pushed to `PyPI`_.
|
tests: PyPI is waiting for your review
|
||||||
If that happens, notify the issues that were fixed about this release.
|
|
||||||
9. Copy this to the start of ``CHANGES.rst``::
|
#. If the release is approved by a maintainer, it will be pushed to `PyPI`_.
|
||||||
|
If that happens, notify the issues that were fixed about this release.
|
||||||
|
#. Copy this to the start of ``CHANGES.rst``.
|
||||||
|
|
||||||
|
.. code-block:: text
|
||||||
|
|
||||||
6.3.1 (unreleased)
|
6.3.1 (unreleased)
|
||||||
------------------
|
------------------
|
||||||
|
|
@ -130,35 +134,41 @@ However, only people with ``PyPI environment access for GitHub Actions`` can app
|
||||||
|
|
||||||
- ...
|
- ...
|
||||||
|
|
||||||
10. Push the new CHANGELOG so it is used for future changes.
|
#. Push the new ``CHANGELOG`` so it is used for future changes.
|
||||||
|
|
||||||
.. code-block:: bash
|
.. code-block:: shell
|
||||||
|
|
||||||
git checkout main
|
git checkout main
|
||||||
git pull
|
git pull
|
||||||
git add CHANGES.rst
|
git add CHANGES.rst
|
||||||
git commit -m"Add new CHANGELOG section for future release
|
git commit -m"Add new CHANGELOG section for future release
|
||||||
|
|
||||||
See https://icalendar.readthedocs.io/en/latest/maintenance.html#new-releases"
|
See https://icalendar.readthedocs.io/en/latest/maintenance.html#new-releases"
|
||||||
git push upstream main # could be origin or whatever reference
|
git push upstream main # could be origin or whatever reference
|
||||||
|
|
||||||
Links
|
Links
|
||||||
-----
|
-----
|
||||||
|
|
||||||
This section contains useful links for maintainers and collaborators:
|
This section contains useful links for maintainers and collaborators.
|
||||||
|
|
||||||
- `Future of icalendar, looking for maintainer #360 <https://github.com/collective/icalendar/discussions/360>`__
|
- `Future of icalendar, looking for maintainer #360 <https://github.com/collective/icalendar/discussions/360>`_
|
||||||
- `Comment on the Plone tests running with icalendar <https://github.com/collective/icalendar/pull/447#issuecomment-1277643634>`__
|
- `Comment on the Plone tests running with icalendar <https://github.com/collective/icalendar/pull/447#issuecomment-1277643634>`_
|
||||||
|
|
||||||
Updating Python Versions
|
|
||||||
|
Updating Python versions
|
||||||
------------------------
|
------------------------
|
||||||
|
|
||||||
When adding support for a new Python version or removing support for an old one, the following files need to be updated:
|
When adding support for a new Python version, or removing support for an old one, the following files need to be updated:
|
||||||
|
|
||||||
1. ``.github/workflows/tests.yml``: Add or remove the Python version from the test matrix.
|
:file:`.github/workflows/tests.yml`
|
||||||
2. ``tox.ini``: Update the ``envlist`` to include or remove the Python version.
|
Add or remove the Python version from the test matrix.
|
||||||
3. ``pyproject.toml``: Update the ``requires-python`` line and the ``classifiers`` list.
|
:file:`tox.ini`
|
||||||
4. ``README.rst``: Update the compatibility information.
|
Update the ``envlist`` to include or remove the Python version.
|
||||||
5. ``docs/maintenance.rst``: Update this list if any new files need to be modified.
|
:file:`pyproject.toml`
|
||||||
|
Update the ``requires-python`` line and the ``classifiers`` list.
|
||||||
|
:file:`README.rst`
|
||||||
|
Update the compatibility information.
|
||||||
|
:file:`docs/maintenance.rst`
|
||||||
|
Update this list if any new files need to be modified.
|
||||||
|
|
||||||
Remember to test the changes thoroughly and update any documentation that mentions supported Python versions.
|
Remember to test the changes thoroughly, and update any documentation that mentions supported Python versions.
|
||||||
|
|
|
||||||
Ładowanie…
Reference in New Issue