v2.0 Series ("Dazzle")
======================
-.. release-notes::
- :branch: stable/2.0
+.. _Release Notes_v2.0.3_stable_2.0:
+
+v2.0.3
+======
+
+.. _Release Notes_v2.0.3_stable_2.0_Bug Fixes:
+
+Bug Fixes
+---------
+
+- If a patch was processed by Patchwork before series support was added, it
+ will not have a series associated with it. As a result, it is not possible
+ to extract the dependencies for that patch from the series. This was not
+ previously handled correctly. A 404 is now raised if this occurs.
+
+- The ``parsemail.sh`` and ``parsemail-batch.sh`` scripts, found in
+ ``patchwork/bin``, will now default to using ``python`` rather than
+ ``python2`` for calling ``manage.py``. This resolves an issue when
+ Patchwork is deployed with a virtualenv.
+
+
+.. _Release Notes_v2.0.2_stable_2.0:
+
+v2.0.2
+======
+
+.. _Release Notes_v2.0.2_stable_2.0_Bug Fixes:
+
+Bug Fixes
+---------
+
+- Resolve some issues caused by parallel parsing of series.
+
+- Poorly formatted email headers are now handled correctly.
+
+- Patches with CRLF newlines are now parsed correctly and these line endings
+ are stripped when saving patches.
+
+- Resolved some issues with pagination.
+
+- Emails from *git-pull-request* v2.14.3+ are now handled correctly.
+
+- Token generation from the web UI is now disabled if the REST API is
+ disabled. This was causing an exception.
+
+- Non-breaking spaces in tags are now handled correctly.
+
+- Patches with no space before the series marker, such as ``PATCH1/8``, are
+ now parsed correctly.
+
+
+.. _Release Notes_v2.0.1_stable_2.0:
+
+v2.0.1
+======
+
+.. _Release Notes_v2.0.1_stable_2.0_Bug Fixes:
+
+Bug Fixes
+---------
+
+- Handle requests for pages out of range.
+
+- Fix SQL permissions scripts for tables and columns added in 2.0.
+
+- Fix filtering of projects by name
+
+- Fix "add to bundle" dropdown
+
+- Performance improvements for the XML-RPC API
+
+
+.. _Release Notes_v2.0.0_stable_2.0:
+
+v2.0.0
+======
+
+.. _Release Notes_v2.0.0_stable_2.0_Prelude:
+
+Prelude
+-------
+
+The v2.0.0 release includes many new features and bug fixes. For full
+information on the options avaiable, you should look at the full release
+notes in detail. However, there are two key features that make v2.0.0 a
+worthwhile upgrade:
+
+- A REST API is now provided, which will eventually replace the legacy
+ XML-RPC API
+- Patch series and series cover letters are now supported
+
+For further information on these features and the other changes in this
+release, review the full release notes.
+
+
+.. _Release Notes_v2.0.0_stable_2.0_New Features:
+
+New Features
+------------
+
+- REST API.
+
+ Previous versions of Patchwork provided an XML-RPC API. This was functional
+ but there were a couple of issues around usability and general design. This
+ API also provided basic versioning information but the existing clients,
+ mostly `pwclient` variants, did not validate this version. Together, this
+ left us with an API that needed work but no way to fix it without breaking
+ every client out there.
+
+ Rather than breaking all those users, make a clean break and provide
+ another API method. REST APIs are the API method de jour providing a number
+ of advantages over XML-RPC APIs, thus, a REST API is chosen. The following
+ resources are exposed over this new API:
+
+ - Bundles
+ - Checks
+ - Projects
+ - People
+ - Users
+ - Patches
+ - Series
+ - Cover letters
+
+ For information on the usage of the API, refer to the `documentation
+ <https://patchwork.readthedocs.io/en/latest/api/rest/>`__.
+
+- Cover letters are now supported.
+
+ Cover letters are often sent in addition to a series of patches. They do
+ not contain a diff and can generally be identified as number 0 of a series.
+ For example::
+
+ [PATCH 0/3] A cover letter
+
+ Cover letters contain useful information that should not be discarded.
+ Both cover letters and replies to these mails are now stored for use with
+ series.
+
+- Series are now supported.
+
+ Series are groups of patches sent as one bundle. For example::
+
+ [PATCH 0/3] A cover letter
+ [PATCH 1/3] The first patch
+ [PATCH 2/3] The second patch
+ [PATCH 3/3] The third patch
+
+ While Patchwork already supports bundles, these must be created manually,
+ defeating the purpose of using series in the first place. Series make use
+ of the information provided in the emails themselves, avoiding this manual
+ step. The series support implemented is basic and does not support
+ versioning. This will be added in a future release.
+
+- All comments now have a permalink which can be used to reference individual
+ replies to patches and cover letters.
+
+- `Django Debug Toolbar <https://pypi.python.org/pypi/django-debug-toolbar>`_
+ is now enabled by defaut when using development settings.
+
+- `Django 1.9 <https://docs.djangoproject.com/en/1.10/releases/1.9/>`_ and
+ `1.10 <https://docs.djangoproject.com/en/1.10/releases/1.10/>`_ are now
+ supported.
+
+- `Python 3.5 <https://www.python.org/downloads/release/python-350/>`_ is now
+ supported.
+
+- `Docker <https://www.docker.com/what-docker#/developers>`_ support is now
+ integrated for development usage. To use this, refer to the `documentation
+ <https://patchwork.readthedocs.io/en/latest/development/installation/>`__.
+
+- Series markers are now parsed from patches generated by the `Mercurial
+ Patchbomb extension
+ <https://www.mercurial-scm.org/wiki/PatchbombExtension>`__.
+
+
+.. _Release Notes_v2.0.0_stable_2.0_Upgrade Notes:
+
+Upgrade Notes
+-------------
+
+- The REST API is enabled by default.
+
+ The REST API is enabled by default. It is possible to disable this API,
+ though this functionality may be removed in a future release. Should you
+ wish to disable this feature, configure the ``ENABLE_REST_API`` setting to
+ ``False``.
+
+- The ``parsemail.py`` and ``parsearchive.py`` scripts have been replaced by
+ the ``parsemail`` and ``parsearchive`` management commands. These can be
+ called like any other management commands. For example::
+
+ $ ./manage.py parsemail [args...]
+
+- The ``DEFAULT_PATCHES_PER_PAGE`` has been renamed as
+ ``DEFAULT_ITEMS_PER_PAGE`` as it is now possible to list cover letters in
+ addition to patches.
+
+- The ``context`` field for patch checks must now be slug, or a string
+ consisting of only ASCII letters, numbers, underscores or hyphens. While
+ older, non-slugified strings won't cause issues, any scripts creating
+ contexts must be updated where necessary.
+
+
+.. _Release Notes_v2.0.0_stable_2.0_Bug Fixes:
+
+Bug Fixes
+---------
+
+- When downloading an mbox, a user's name will now be set to the name used in
+ the last email recieved from them. Previously, the name used in the first
+ email received from a user was used.
+
+- `user at domain`-style email addresses, commonly found in Mailman archives,
+ are now handled correctly.
+
+- Unicode characters transmitted over the XML-RPC API are now handled
+ correctly under Python 3
+
+- The `pwclient` tool will no longer attempt to re-encode unicode to ascii
+ bytes, which was a frequent cause of ``UnicodeEncodeError`` exceptions.
+ Instead, a warning is produced if your environement is not configured for
+ unicode.
+
+
+.. _Release Notes_v2.0.0_stable_2.0_Other Notes:
+
+Other Notes
+-----------
+
+- `reno <https://pypi.python.org/pypi/reno>`_ is now used for release note
+ management.
+
+- Patch diffs now download with a ``diff`` extension.
v2.1 Series ("Eolienne")
========================
-.. release-notes::
- :branch: stable/2.1
+.. _Release Notes_v2.1.5-4_stable_2.1:
+
+v2.1.5-4
+========
+
+.. _Release Notes_v2.1.5-4_stable_2.1_Bug Fixes:
+
+Bug Fixes
+---------
+
+- An sql error was fixed in `lib/sql/grant-all.postgres.sql`.
+
+
+.. _Release Notes_v2.1.4_stable_2.1:
+
+v2.1.4
+======
+
+.. _Release Notes_v2.1.4_stable_2.1_Bug Fixes:
+
+Bug Fixes
+---------
+
+- CVE-2019-13122 has been fixed. Andrew Donnellan discovered an XSS
+ via the message-id field. A malicious user could send a patch with
+ a message ID that included a script tag. Because of the quirks of
+ the email RFCs, such a message ID can survive being sent through
+ many mail systems, including Gmail, and be parsed and stored by
+ Patchwork. When a user viewed a patch detail page for the patch
+ with this message id, the script would be run. This is fixed by
+ properly escaping the field before it is rendered.
+
+- The ``pwclientrc`` samples generated by Patchwork were previously not valid
+ INI files. This issue is resolved. (`#277
+ <https://github.com/getpatchwork/patchwork/issues/277>`__)
+
+
+.. _Release Notes_v2.1.3_stable_2.1:
+
+v2.1.3
+======
+
+.. _Release Notes_v2.1.3_stable_2.1_Bug Fixes:
+
+Bug Fixes
+---------
+
+- `#197`__ was the result of a issue with OzLabs instance and not Patchwork
+ itself, and the fix included actually ended up corrupting subjects for
+ everyone. It has now been reverted.
+
+ __ https://github.com/getpatchwork/patchwork/issues/197
+
+- In the past, Patchwork used to support filtering patches that weren't
+ delegated to anyone. This feature was removed in v1.1.0, as part of a patch
+ designed to support delegation to anyone. However, that feature didn't scale
+ and was later removed. The ability to delegate to anyone is now itself
+ re-introduced.
+
+
+.. _Release Notes_v2.1.2_stable_2.1:
+
+v2.1.2
+======
+
+.. _Release Notes_v2.1.2_stable_2.1_Upgrade Notes:
+
+Upgrade Notes
+-------------
+
+- `django-filter 1.1
+ <https://github.com/carltongibson/django-filter/releases/tag/1.1.0>`_ is
+ now supported.
+
+- `Django REST Framework 3.7
+ <http://www.django-rest-framework.org/topics/release-notes/#370/>`_ is now
+ supported.
+
+- `Django REST Framework 3.8
+ <http://www.django-rest-framework.org/topics/release-notes/#380/>`_ is now
+ supported.
+
+- `Django REST Framework 3.9
+ <https://www.django-rest-framework.org/community/3.9-announcement/>`_ is now
+ supported.
+
+
+.. _Release Notes_v2.1.2_stable_2.1_Bug Fixes:
+
+Bug Fixes
+---------
+
+- Assigning maintained projects when creating a new user in the admin page
+ was causing an error. This is now resolved.
+
+- Long headers can be wrapped using CRLF followed by WSP (whitespace). This
+ whitespace was not being stripped, resulting in errant whitespace being
+ saved for the patch subject. This is resolved though existing patches and
+ cover letters will need to be updated manually.
+
+- API resources with embedded series were not showing the ``web_url`` value
+ for these series. This is now shown.
+
+- Showing comments for a non-existant patch or cover letter was returning an
+ empty response instead of a HTTP 404. This issue is resolved for both
+ resources.
+
+- Showing checks for a non-existant patch was returning an empty response
+ instead of a HTTP 404. Similarly, attempting to create a new check against
+ this patch would result in a HTTP 5xx error instead of a HTTP 404. Both
+ issues are now resolved.
+
+- Fields added in API v1.1 are now consistently excluded when requesting API
+ v1.0, as was intended.
+
+
+.. _Release Notes_v2.1.1_stable_2.1:
+
+v2.1.1
+======
+
+.. _Release Notes_v2.1.1_stable_2.1_Bug Fixes:
+
+Bug Fixes
+---------
+
+- An issue that resulted in checks for all patches being listed for each
+ patch is resolved.
+ (`#203 <https://github.com/getpatchwork/patchwork/issues/203>`__)
+
+- An issue that prevented updating of delegates using the REST API is
+ resolved. (`#216 <https://github.com/getpatchwork/patchwork/issues/216>`__)
+
+- A project's ``list_email``, ``list_id`` and ``link_name`` fields can no
+ longer be updated via the REST API. This is a superuser-only operation
+ that, for now, should only be done via the admin interface.
+ (`#217 <https://github.com/getpatchwork/patchwork/issues/217>`__)
+
+- It's now possible to assign patches to existing bundles from a user's TODO
+ page.
+ (`#213 <https://github.com/getpatchwork/patchwork/issues/213>`__)
+
+- The delegate and submitter fields will remain populated when moving
+ between different pages or changing filters.
+ (`#78 <https://github.com/getpatchwork/patchwork/issues/78>`__)
+
+
+.. _Release Notes_v2.1.0_stable_2.1:
+
+v2.1.0
+======
+
+.. _Release Notes_v2.1.0_stable_2.1_Prelude:
+
+Prelude
+-------
+
+The key part of this release is a major performance fix -
+denormalising the project field into patch model so that counting a
+project's patches doesn't require a JOIN. This requires a migration
+and so isn't suitable for a stable backport. Event listing in the API
+has also been sped up by refactoring the queries.
+
+This release also includes the feature development that had accrued in
+the mean time and numerous bug fixes.
+
+The REST API version has been bumped to 1.1.
+
+
+.. _Release Notes_v2.1.0_stable_2.1_New Features:
+
+New Features
+------------
+
+- `Django 1.11 <https://docs.djangoproject.com/en/1.11/releases/1.11/>`_ is
+ now supported.
+
+- Allow list filtering into multiple projects (and email dropping) based on
+ subject prefixes. Enable by specifying a regular expression which needs to
+ be matched in the subject on a per-project basis (field ``subject_match``).
+ Project with empty ``subject_match`` field (and matching ``list_id``)
+ serves as a default in case of no match.
+
+- The ``pwclient get`` command will now download patches with a ``.patch``
+ extension.
+
+- `Python 3.6 <https://www.python.org/downloads/release/python-360/>`_ is now
+ supported.
+
+
+.. _Release Notes_v2.1.0_stable_2.1_Known Issues:
+
+Known Issues
+------------
+
+- Series parsing in the presence of parallel mail processing is still unreliable.
+
+- Several more minor issues can be browsed on our `issue tracker <https://github.com/getpatchwork/patchwork/issues>`_.
+
+
+.. _Release Notes_v2.1.0_stable_2.1_Upgrade Notes:
+
+Upgrade Notes
+-------------
+
+- Django 1.6 and 1.7 are no longer supported. These are no longer supported
+ upstream and most distributions provide a newer version.
+
+- django-filter 0.11 is no longer supported. This was only used with Django
+ 1.6 and 1.7 and is not compatible with any version supported by Patchwork.
+
+
+.. _Release Notes_v2.1.0_stable_2.1_Bug Fixes:
+
+Bug Fixes
+---------
+
+- If a patch was processed by Patchwork before series support was added, it
+ will not have a series associated with it. As a result, it is not possible
+ to extract the dependencies for that patch from the series. This was not
+ previously handled correctly. A 404 is now raised if this occurs.
+
+- A nasty race condition bug that could cause patches in a series to be dropped has been fixed.
+
+- The ``parsemail.sh`` and ``parsemail-batch.sh`` scripts, found in
+ ``patchwork/bin``, will now default to using ``python`` rather than
+ ``python2`` for calling ``manage.py``. This resolves an issue when
+ Patchwork is deployed with a virtualenv.
+
+
+.. _Release Notes_v2.1.0_stable_2.1_API Changes:
+
+API Changes
+-----------
+
+- Links to related comments are now exposed when checking patch and cover
+ letter details. The comments themselves are then available via
+ ``/patches/{patchID}/comments`` and ``/covers/{coverID}/comments``
+ endpoints. Please note that comments are available only since API
+ version 1.1
+
+- Cover letters embedded in other responses now provide an mbox link, which
+ can be used to download the cover letter and associated metadata (tags) in
+ mbox format.
+
+- Series, patches and cover letters can be filtered by submitter using email
+ addresses. For example:
+
+ .. code-block:: shell
+
+ $ curl /covers/?submitter=stephen@that.guru
+
+- Bundles can be filtered by owner, patches by delegate and checks by user
+ using username. For example:
+
+ .. code-block:: shell
+
+ $ curl /bundles/?owner=stephenfin
+
+- Filters can now be specified multiple times. For example:
+
+ .. code-block:: shell
+
+ $ curl /patches/?state=under-review&state=rfc
+
+ This operates as a logical OR: it will retrieve patches that are either
+ Under Review or RFC.
+
+- The ``/project`` endpoint now exposes a ``subject_match`` attribute.
+
+- Messages headers that use the same key, such as ``Received:`` are now
+ combined into a list. Previously only one of the values would be output.
+ This affects the ``/covers`` and ``/patches`` endpoints.
+
+
+.. _Release Notes_v2.1.0_stable_2.1_Other Notes:
+
+Other Notes
+-----------
+
+- The patch ID on the patch detail page can now be clicked to copy it. This
+ is similar to what we already do on the patch list page.
+
+- mbox files now contain all headers from the original email. This also means
+ the ``Subject:`` header included will contain the original subject and not
+ the parsed Patchwork's version.
+
+- Unify timezones used -- use UTC for both email submissions and internal
+ events. Please note that this change doesn't modify already existing data
+ so in case the instance's timezone is UTC+XX, events will appear out of
+ order (as if they happened earlier) for XX hours in the events API feed.
v2.2 Series ("Flannel")
=======================
-.. release-notes::
- :branch: stable/2.2
+.. _Release Notes_v2.2.4_stable_2.2:
+
+v2.2.4
+======
+
+.. _Release Notes_v2.2.4_stable_2.2_API Changes:
+
+API Changes
+-----------
+
+- The ``list_archive_url`` field will now be correctly shown for patch
+ comments and cover letter comments.
+ (`#391 <https://github.com/getpatchwork/patchwork/issues/391>`__)
+
+
+.. _Release Notes_v2.2.3_stable_2.2:
+
+v2.2.3
+======
+
+.. _Release Notes_v2.2.3_stable_2.2_Bug Fixes:
+
+Bug Fixes
+---------
+
+- Resolve a bug that would prevent listing patches for a project via the
+ browseable API view when logged in with admin permissions (`issue #379`__)
+
+ __ https://github.com/getpatchwork/patchwork/issues/379
+
+
+.. _Release Notes_v2.2.2_stable_2.2:
+
+v2.2.2
+======
+
+.. _Release Notes_v2.2.2_stable_2.2_Bug Fixes:
+
+Bug Fixes
+---------
+
+- An issue that preventing updating bundles via the REST API without
+ updating the included patches has been resolved.
+ (`#357 <https://github.com/getpatchwork/patchwork/issues/357>`__)
+
+- The parser module now uses an atomic select-insert when creating new patch,
+ cover letter and comment entries. This prevents the integrity errors from
+ being logged in the DB logs.
+ (`#358 <https://github.com/getpatchwork/patchwork/issues/358>`__)
+
+
+.. _Release Notes_v2.2.1_stable_2.2:
+
+v2.2.1
+======
+
+.. _Release Notes_v2.2.1_stable_2.2_API Changes:
+
+API Changes
+-----------
+
+- The REST API now supports filtering patches and cover letters by message
+ ID, using the ``msgid`` query parameter. Don't include leading or trailing
+ angle brackets.
+
+
+.. _Release Notes_v2.2.0_stable_2.2:
+
+v2.2.0
+======
+
+.. _Release Notes_v2.2.0_stable_2.2_New Features:
+
+New Features
+------------
+
+- Patches can now be related to other patches (e.g. to cross-reference
+ revisions). Relations can be set via the REST API by maintainers
+ (currently only for patches of projects they maintain). Patches can
+ belong to at most one relation at a time.
+
+- `Django 2.0 <https://docs.djangoproject.com/en/2.0/releases/2.0/>`_ is now
+ supported. This requires Python 3.
+
+- `Django 2.1 <https://docs.djangoproject.com/en/dev/releases/2.1/>`_ is now
+ supported. This requires Python 3.
+
+- `Django 2.2 <https://docs.djangoproject.com/en/dev/releases/2.2/>`_ is now
+ supported. This requires Python 3.
+
+- The ``patch-delegated``, ``patch-state-changed`` and ``check-created``
+ events now have an ``actor`` associated with them - the user that updated
+ the patch or created the check. For other event types, this attribute is
+ present but unset.
+
+- Add a field to Project to store a link to the project's mailing list
+ archive, and display that on the project info page.
+
+- Add a field to Project to store a URL format for a Message-ID redirector
+ for the project's mailing list archive, and display a link to the email
+ thread for each patch.
+
+- Exporting patchwork projects as mbox files and optionally compressing them
+ is now possible with the ``./manage exportproject`` management command.
+
+- The URL schema now uses message IDs, rather than patch IDs, by
+ default. Old URLs will redirect to the new URLs.
+
+- `Python 3.7 <https://www.python.org/downloads/release/python-370/>`_ is now
+ supported.
+
+- `Python 3.8 <https://www.python.org/downloads/release/python-380/>`_ is now
+ supported.
+
+
+.. _Release Notes_v2.2.0_stable_2.2_Upgrade Notes:
+
+Upgrade Notes
+-------------
+
+- `django-filter 1.1
+ <https://github.com/carltongibson/django-filter/releases/tag/1.1.0>`_ is
+ now supported.
+
+- `django-filter 2.0
+ <https://github.com/carltongibson/django-filter/releases/tag/2.0.0>`_ is
+ now supported. This requires Python 3.
+
+- `Django REST Framework 3.10
+ <https://www.django-rest-framework.org/community/3.10-announcement/>`_ is
+ now supported.
+
+- `Django REST Framework 3.11
+ <https://www.django-rest-framework.org/community/3.11-announcement/>`_ is
+ now supported.
+
+- `Django REST Framework 3.7
+ <https://www.django-rest-framework.org/community/3.7-announcement/>`_ is now
+ supported.
+
+- `Django REST Framework 3.8
+ <https://www.django-rest-framework.org/community/3.8-announcement/>`_ is now
+ supported.
+
+- `Django REST Framework 3.9
+ <https://www.django-rest-framework.org/community/3.9-announcement/>`_ is now
+ supported.
+
+- Python 3.4 is no longer supported. This is no longer supported upstream and
+ most distributions provide a newer version.
+
+- Django 1.8, 1.9 and 1.10 are no longer supported. These are no longer
+ supported upstream and most distributions provide a newer version.
+
+- djangorestframework 3.4 and 3.5 are no longer supported. These were only
+ used with Django 1.8 to 1.10 and are not compatible with any version
+ now supported by Patchwork.
+
+- ``pwclient`` is no longer packaged with Patchwork. Instead, it is developed
+ as a separate project on `GitHub`__ and available from `PyPI`__.
+
+ __ https://github.com/getpatchwork/pwclient
+ __ https://pypi.org/project/pwclient/
+
+
+.. _Release Notes_v2.2.0_stable_2.2_Bug Fixes:
+
+Bug Fixes
+---------
+
+- CVE-2019-13122 has been fixed. Andrew Donnellan discovered an XSS
+ via the message-id field. A malicious user could send a patch with
+ a message ID that included a script tag. Because of the quirks of
+ the email RFCs, such a message ID can survive being sent through
+ many mail systems, including Gmail, and be parsed and stored by
+ Patchwork. When a user viewed a patch detail page for the patch
+ with this message id, the script would be run. This is fixed by
+ properly escaping the field before it is rendered.
+
+- Queries to the REST API with filters are now significantly faster: slow
+ database queries were reworked.
+
+- To avoid triggering spam filters due to failed signature validation, many
+ mailing lists mangle the From header to change the From address to be the
+ address of the list, typically where the sender's domain has a strict DMARC
+ policy enabled. This leads to incorrect senders being recorded. We now try
+ to unmangle the From header using the X-Original-From or Reply-To headers,
+ as used by Google Groups and Mailman respectively.
+
+- Assigning maintained projects when creating a new user in the admin page
+ was causing an error. This is now resolved.
+
+- Long headers can be wrapped using CRLF followed by WSP (whitespace). This
+ whitespace was not being stripped, resulting in errant whitespace being
+ saved for the patch subject. This is resolved though existing patches and
+ cover letters will need to be updated manually.
+
+- An issue that resulted in checks for all patches being listed for each
+ patch is resolved.
+ (`#203 <https://github.com/getpatchwork/patchwork/issues/203>`__)
+
+- An issue that prevented updating of delegates using the REST API is
+ resolved. (`#216 <https://github.com/getpatchwork/patchwork/issues/216>`__)
+
+- A project's ``list_email``, ``list_id`` and ``link_name`` fields can no
+ longer be updated via the REST API. This is a superuser-only operation
+ that, for now, should only be done via the admin interface.
+ (`#217 <https://github.com/getpatchwork/patchwork/issues/217>`__)
+
+- It's now possible to assign patches to existing bundles from a user's TODO
+ page.
+ (`#213 <https://github.com/getpatchwork/patchwork/issues/213>`__)
+
+- API resources with embedded series were not showing the ``web_url`` value
+ for these series. This is now shown.
+
+- Showing comments for a non-existant patch or cover letter was returning an
+ empty response instead of a HTTP 404. This issue is resolved for both
+ resources.
+
+- Showing checks for a non-existant patch was returning an empty response
+ instead of a HTTP 404. Similarly, attempting to create a new check against
+ this patch would result in a HTTP 5xx error instead of a HTTP 404. Both
+ issues are now resolved.
+
+- Fields added in API v1.1 are now consistently excluded when requesting API
+ v1.0, as was intended.
+
+- `#197`__ was the result of a issue with OzLabs instance and not Patchwork
+ itself, and the fix included actually ended up corrupting subjects for
+ everyone. It has now been reverted.
+
+ __ https://github.com/getpatchwork/patchwork/issues/197
+
+- The ``pwclientrc`` samples generated by Patchwork were previously not valid
+ INI files. This issue is resolved. (`#277
+ <https://github.com/getpatchwork/patchwork/issues/277>`__)
+
+- A bug that would result in patches from later series revisions being
+ included in earlier revisions has been resolved.
+
+- Previously, attempting to retrieve a patch that did not exist would result
+ in a ``HTTP 500`` (Internal Server Error) being raised. This has been
+ corrected and a ``HTTP 404`` (Not Found) is now raised instead.
+
+- In the past, Patchwork used to support filtering patches that weren't
+ delegated to anyone. This feature was removed in v1.1.0, as part of a patch
+ designed to support delegation to anyone. However, that feature didn't scale
+ and was later removed. The ability to delegate to anyone is now itself
+ re-introduced.
+
+- The delegate and submitter fields will remain populated when moving
+ between different pages or changing filters.
+ (`#78 <https://github.com/getpatchwork/patchwork/issues/78>`__)
+
+
+.. _Release Notes_v2.2.0_stable_2.2_API Changes:
+
+API Changes
+-----------
+
+- Relations are available via ``/patches/{patchID}/`` endpoint, in
+ the ``related`` field.
+
+- Allow ordering events from the events API by date. This can be done by
+ adding ``order=date`` or ``order=-date`` (the default) parameters.
+
+- The ``/event`` API now exposes an ``actor`` attribute. It is possible to
+ filter events by this attribute.
+
+- The API version has been updated to v1.2.
+
+- Projects now expose the ``list_archive_url`` and
+ ``list_archive_url_format`` attributes.
+
+- Patches, comments and cover letters now expose a ``list_archive_url``
+ attribute.
+
+- The REST API now supports filtering patches by their hashes, using the
+ ``hash`` query parameter.
+
+- Bundles can now be created, updated and deleted via the REST API.
+
+
+.. _Release Notes_v2.2.0_stable_2.2_Security Notes:
+
+Security Notes
+--------------
+
+- Change the recommended method for generating the Django secret key to use a
+ cryptographically secure random number generator.
+
+
+.. _Release Notes_v2.2.0_stable_2.2_Other Notes:
+
+Other Notes
+-----------
+
+- The performance of various pages has been improved with the addition of
+ some database indexes and optimization of some queries.
v3.0 Series ("Grosgrain")
=========================
-.. release-notes::
- :branch: stable/3.0
+.. _Release Notes_v3.0.5_stable_3.0:
+
+v3.0.5
+======
+
+.. _Release Notes_v3.0.5_stable_3.0_Bug Fixes:
+
+Bug Fixes
+---------
+
+- Comments and whitespace are now correctly stripped from the ``Message-ID``,
+ ``In-Reply-To``, and ``References`` headers. One side effect of this change
+ is that the parser is now stricter with regards to the format of the
+ ``msg-id`` component of these headers: all identifiers must now be
+ surrounded by angle brackets, e.g. ``<abcdef@example.com>``. This is
+ mandated in the spec and a review of mailing lists archives suggest it is
+ broadly adhered to. Without these markers, there is no way to delimit
+ ``msg-id`` from any surrounding comments and whitespace.
+
+
+.. _Release Notes_v3.0.1_stable_3.0:
+
+v3.0.1
+======
+
+.. _Release Notes_v3.0.1_stable_3.0_Bug Fixes:
+
+Bug Fixes
+---------
+
+- Fixed a compatability issue with Django 3.1 that prevented users from
+ resetting their password.
+ (`#394 <https://github.com/getpatchwork/patchwork/issues/394>`__)
+
+
+.. _Release Notes_v3.0.1_stable_3.0_API Changes:
+
+API Changes
+-----------
+
+- The ``list_archive_url`` field will now be correctly shown for patch
+ comments and cover letter comments.
+ (`#391 <https://github.com/getpatchwork/patchwork/issues/391>`__)
+
+
+.. _Release Notes_v3.0.0_stable_3.0:
+
+v3.0.0
+======
+
+.. _Release Notes_v3.0.0_stable_3.0_Prelude:
+
+Prelude
+-------
+
+There are two main changes in this release: the removal of Python 2.7 support
+and the resolution of the longstanding performance issues introduced by the
+``Submission`` model. On top of this, there is the usual bump in
+requirements, a significant amount of fixes to the documentation for the
+REST API, and the squashing of all migrations introduced in versions up to
+and including v2.2.0.
+
+
+.. _Release Notes_v3.0.0_stable_3.0_New Features:
+
+New Features
+------------
+
+- `Django 3.0 <https://docs.djangoproject.com/en/dev/releases/3.0/>`_ is
+ now supported.
+
+- `Django 3.1 <https://docs.djangoproject.com/en/dev/releases/3.1/>`_ is
+ now supported.
+
+- `Django REST Framework 3.12
+ <https://www.django-rest-framework.org/community/3.12-announcement/>`_ is
+ now supported.
+
+- `Python 3.9 <https://www.python.org/downloads/release/python-390/>`_ is now
+ supported.
+
+
+.. _Release Notes_v3.0.0_stable_3.0_Upgrade Notes:
+
+Upgrade Notes
+-------------
+
+- Django 1.11, 2.0 and 2.1 are no longer supported. These are no longer
+ supported upstream and most distributions provide a newer version.
+
+- djangorestframework 3.6, 3.7, 3.8 and 3.9 are no longer supported. These
+ were only used with Django 1.11 to 2.1 and are not compatible with any
+ version now supported by Patchwork.
+
+- django-filter 1.1.0 is no longer supported. This was only used with Django
+ 1.11 and is not compatible with any version now supported by Patchwork.
+
+- Python 2.7 and 3.5 are no longer supported. These are no longer supported
+ upstream and most distributions provide a newer version.
+
+
+.. _Release Notes_v3.0.0_stable_3.0_Bug Fixes:
+
+Bug Fixes
+---------
+
+- An issue that preventing updating bundles via the REST API without
+ updating the included patches has been resolved.
+ (`#357 <https://github.com/getpatchwork/patchwork/issues/357>`__)
+
+- The parser module now uses an atomic select-insert when creating new patch,
+ cover letter and comment entries. This prevents the integrity errors from
+ being logged in the DB logs.
+ (`#358 <https://github.com/getpatchwork/patchwork/issues/358>`__)
+
+- Resolve a bug that would prevent listing patches for a project via the
+ browseable API view when logged in with admin permissions (`issue #379`__)
+
+ __ https://github.com/getpatchwork/patchwork/issues/379
+
+- Previously, it was possible to create a project with a ``linkname``
+ containing invalid URL characters. This would result in broken URLs. We
+ now validate this field and restrict characters to unicode slugs (unicode
+ letters, numbers, underscores and hyphens).
+
+
+.. _Release Notes_v3.0.0_stable_3.0_API Changes:
+
+API Changes
+-----------
+
+- The REST API now supports filtering patches and cover letters by message
+ ID, using the ``msgid`` query parameter. Don't include leading or trailing
+ angle brackets.
v3.1 Series ("Hessian")
=======================
-.. release-notes::
- :branch: stable/3.1
+.. _Release Notes_v3.1.1_stable_3.1:
+
+v3.1.1
+======
+
+.. _Release Notes_v3.1.1_stable_3.1_New Features:
+
+New Features
+------------
+
+- The version of Django used is now checked on start-up. This can help avoid
+ issues where deployers forget to update their Django version and see odd
+ behavior as a result.
+
+
+.. _Release Notes_v3.1.1_stable_3.1_Bug Fixes:
+
+Bug Fixes
+---------
+
+- Fix an issue whereby comment-based events would cause a HTTP 500 error
+ for the events API (``/api/events``).
+
+
+.. _Release Notes_v3.1.0_stable_3.1:
+
+v3.1.0
+======
+
+.. _Release Notes_v3.1.0_stable_3.1_Prelude:
+
+Prelude
+-------
+
+This release is one of the smaller releases. The primary new feature is the ability to mark comments as addressed/unaddressed, allowing maintainers to track work items. In addition, two new events have been added to the ``/events`` API: ``cover-comment-created`` and ``patch-comment-created``. Recent versions of Python (3.10) and Django (3.2, 4.0) are now supported, while support for older Python (3.6) and Django (2.2, 3.0, 3.1) versions has been removed. More information on all the above is included below.
+
+
+.. _Release Notes_v3.1.0_stable_3.1_New Features:
+
+New Features
+------------
+
+- Patch comments and cover letter comments can be marked 'addressed' or 'unaddressed' to
+ reflect whether the comment has been addressed by the patch and cover letter submitter
+ or a reviewer. The current state of a comment is shown in the header when showing a
+ comment and users with edit permission can toggle the state using an adjacent button.
+
+- Two new event types have been added: ``cover-comment-created`` and
+ ``patch-comment-created``. As their names would suggest, these track the
+ creation of new cover letter and patch comments respectively.
+
+- `Django 3.2 <https://docs.djangoproject.com/en/dev/releases/3.2/>`_ is now
+ supported.
+
+- `Django 4.0 <https://docs.djangoproject.com/en/dev/releases/4.0/>`_ is
+ now supported.
+
+- The ``Link`` header included in REST API responses now includes ``first``
+ and ``last`` relations, as described in `RFC 5988`__. As their name would
+ suggest, these can be used to navigate to the beginning and end of the
+ resource.
+
+ .. __: https://datatracker.ietf.org/doc/html/rfc5988
+
+- `Python 3.10 <https://www.python.org/downloads/release/python-3100/>`_ is
+ now supported.
+
+
+.. _Release Notes_v3.1.0_stable_3.1_Upgrade Notes:
+
+Upgrade Notes
+-------------
+
+- Django 3.0 is no longer supported. It is no longer supported upstream and
+ most distributions provide a newer version.
+
+- Django 3.1 is no longer supported. It is no longer supported upstream and
+ most distributions provide a newer version.
+
+- Python 3.6 is no longer supported. It is no longer supported upstream and
+ most distributions provide a newer version.
+
+- Django 2.2 is no longer supported. Is is no longer supported upstream and
+ most distributions provide a newer version.
+
+- Database configuration has been added to ``patchwork.settings.base``.
+ Previously, this had to be specified in the ``settings.py`` file manually
+ created by admins. The following environment variables can now be used to
+ configure the settings:
+
+ - ``DATABASE_TYPE`` (one of: ``postgres``, ``sqlite3``, ``mysql``;
+ default: ``mysql``)
+ - ``DATABASE_HOST`` (default: ``localhost``)
+ - ``DATABASE_PORT`` (default: ``<unset>``)
+ - ``DATABASE_NAME`` (default: ``patchwork``)
+ - ``DATABASE_USER`` (default: ``patchwork``)
+ - ``DATABASE_PASSWORD`` (default: ``patchwork``)
+
+ If you are manually defining ``DATABASES`` in your ``settings.py`` file,
+ this should have no impact. However, you may wish to rework your deployment
+ to use environment variables instead.
+
+- Database configuration variables ``PW_TEST_DB_*`` are renamed to their
+ corresponding ``DATABASE_*`` names to sync development & production
+ environments setup. Some mistaken references to ``DATABASE_PASS`` are
+ also replaced with ``DATABASE_PASSWORD`` to follow the convention.
+
+
+.. _Release Notes_v3.1.0_stable_3.1_Bug Fixes:
+
+Bug Fixes
+---------
+
+- Fixed a compatability issue with Django 3.1 that prevented users from
+ resetting their password.
+ (`#394 <https://github.com/getpatchwork/patchwork/issues/394>`__)
+
+- Comments and whitespace are now correctly stripped from the ``Message-ID``,
+ ``In-Reply-To``, and ``References`` headers. One side effect of this change
+ is that the parser is now stricter with regards to the format of the
+ ``msg-id`` component of these headers: all identifiers must now be
+ surrounded by angle brackets, e.g. ``<abcdef@example.com>``. This is
+ mandated in the spec and a review of mailing lists archives suggest it is
+ broadly adhered to. Without these markers, there is no way to delimit
+ ``msg-id`` from any surrounding comments and whitespace.
+
+
+.. _Release Notes_v3.1.0_stable_3.1_API Changes:
+
+API Changes
+-----------
+
+- The API version has been updated to v1.3.
+
+- A new REST API endpoint is available at ``/api/covers/<cover_id>/comments/<comment_id>/``.
+ This can be used to retrieve and update (e.g. ``addressed`` state) details about a specific
+ cover comment.
+
+- A new REST API endpoint is available at ``/api/patches/<patch_id>/comments/<comment_id>/``.
+ This can be used to retrieve and update (e.g. ``addressed`` state) details about a specific
+ patch comment.
+
+- The ``list_archive_url`` field will now be correctly shown for patch
+ comments and cover letter comments.
+ (`#391 <https://github.com/getpatchwork/patchwork/issues/391>`__)
projects / thirdparty / patchwork.git / commitdiff
