kopia lustrzana https://github.com/collective/icalendar
Use proper semantic markup for files and definition list
rodzic
190ded5835
commit
8d33bcd3c7
|
@ -30,11 +30,11 @@ Maintainers need the following permissions.
|
|||
Collaborators
|
||||
-------------
|
||||
|
||||
Collaborators are people with write access to the repository.
|
||||
Collaborators have write access to the repository.
|
||||
As a collaborator, you can
|
||||
|
||||
- merge Pull Requests,
|
||||
- initiate a new release, see below.
|
||||
- merge pull requests, and
|
||||
- initiate a new release.
|
||||
|
||||
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
|
||||
|
||||
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,
|
||||
you can ask for becoming a collaborator or a maintainer asks you if you would like to become one.
|
||||
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.
|
||||
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.
|
||||
However, only people with ``PyPI environment access for GitHub Actions`` can approve an automated release to PyPI.
|
||||
Since collaborators and maintainers have write access to the repository, they can start the release process.
|
||||
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>`__
|
||||
and the version you want to release is correctly named.
|
||||
.. code-block:: shell
|
||||
|
||||
.. 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
|
||||
git pull
|
||||
git checkout -b release main
|
||||
git add CHANGES.rst
|
||||
git commit -m"version $VERSION"
|
||||
#. Push the commit and `create a pull request <https://github.com/collective/icalendar/compare?expand=1>`_.
|
||||
Here is an `example pull request #457 <https://github.com/collective/icalendar/pull/457>`_.
|
||||
|
||||
3. Push the commit and `create a pull request <https://github.com/collective/icalendar/compare?expand=1>`__
|
||||
Here is an `example pull request #457 <https://github.com/collective/icalendar/pull/457>`__.
|
||||
.. code-block:: shell
|
||||
|
||||
.. 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.
|
||||
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!
|
||||
#. Clean up behind you!
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: shell
|
||||
|
||||
git checkout main
|
||||
git pull
|
||||
git branch -d release
|
||||
git push -d origin release
|
||||
git checkout main
|
||||
git pull
|
||||
git branch -d 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 pull
|
||||
git tag "v$VERSION"
|
||||
git push upstream "v$VERSION" # could be origin or whatever reference
|
||||
git checkout main
|
||||
git pull
|
||||
git tag "v$VERSION"
|
||||
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`_.
|
||||
If that happens, notify the issues that were fixed about this release.
|
||||
9. Copy this to the start of ``CHANGES.rst``::
|
||||
tests: PyPI is waiting for your review
|
||||
|
||||
#. 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)
|
||||
------------------
|
||||
|
@ -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 pull
|
||||
git add CHANGES.rst
|
||||
git commit -m"Add new CHANGELOG section for future release
|
||||
git checkout main
|
||||
git pull
|
||||
git add CHANGES.rst
|
||||
git commit -m"Add new CHANGELOG section for future release
|
||||
|
||||
See https://icalendar.readthedocs.io/en/latest/maintenance.html#new-releases"
|
||||
git push upstream main # could be origin or whatever reference
|
||||
See https://icalendar.readthedocs.io/en/latest/maintenance.html#new-releases"
|
||||
git push upstream main # could be origin or whatever reference
|
||||
|
||||
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>`__
|
||||
- `Comment on the Plone tests running with icalendar <https://github.com/collective/icalendar/pull/447#issuecomment-1277643634>`__
|
||||
- `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>`_
|
||||
|
||||
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.
|
||||
2. ``tox.ini``: Update the ``envlist`` to include or remove the Python version.
|
||||
3. ``pyproject.toml``: Update the ``requires-python`` line and the ``classifiers`` list.
|
||||
4. ``README.rst``: Update the compatibility information.
|
||||
5. ``docs/maintenance.rst``: Update this list if any new files need to be modified.
|
||||
:file:`.github/workflows/tests.yml`
|
||||
Add or remove the Python version from the test matrix.
|
||||
:file:`tox.ini`
|
||||
Update the ``envlist`` to include or remove the Python version.
|
||||
: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