From 92714d87e7ebd8d90fee489a1ffc1ca89347a84b Mon Sep 17 00:00:00 2001 From: Sage Abdullah Date: Tue, 12 Nov 2024 10:56:29 +0000 Subject: [PATCH] Minor tweaks per code review --- docs/contributing/release_process.md | 29 ++++++++++++++-------------- docs/releases/upgrading.md | 10 ++++++---- 2 files changed, 21 insertions(+), 18 deletions(-) diff --git a/docs/contributing/release_process.md b/docs/contributing/release_process.md index cd30ce5684..b58931912d 100644 --- a/docs/contributing/release_process.md +++ b/docs/contributing/release_process.md @@ -46,15 +46,15 @@ be "yes." A feature release will usually stop receiving patch release updates when the next feature release comes out. -**Long-term support release** +**Long-term support (LTS) release** -Certain feature releases will be designated as long-term support (LTS) -releases. These releases will get security and data loss fixes applied for -a guaranteed period of time. Typically, a Long Term Support release will happen -once every four feature releases and receive updates for five feature releases, -giving a support period of fifteen months with a three month overlap. +Certain feature releases will be designated as long-term support releases. These +releases will get security and data loss fixes applied for a guaranteed period +of time. Typically, a long-term support release will happen once every four feature releases and receive updates for five feature releases, giving a support +period of fifteen months with a three month overlap. -Also, Long Term Support releases will ensure compatibility with at least one [Django Long Term Support release](https://www.djangoproject.com/download/#supported-versions). +Also, long-term support releases will ensure compatibility with at least one +[Django long-term support release](https://www.djangoproject.com/download/#supported-versions). **Major release** @@ -83,9 +83,9 @@ corresponding API reference, which tend to be more actively developed. We try to strike the balance between: -- keeping the API stable for most users, -- documenting features for advanced developers and third-party package maintainers, and -- allowing for continuous improvement of Wagtail's internals. +- keeping the API stable for most users, +- documenting features for advanced developers and third-party package maintainers, and +- allowing for continuous improvement of Wagtail's internals. A feature release may deprecate certain features from previous releases. If a feature is deprecated in feature release A.x, it will continue to work in all @@ -209,10 +209,11 @@ features to include in the next version. This should include a good deal of preliminary work on those features -- working code trumps grand design. The development team will announce a roadmap update for the next feature -release in the form of an RFC to -[Wagtail's RFCs repository](https://github.com/wagtail/rfcs). After the RFC is -approved, the roadmap update will be available on -[wagtail.org/roadmap](https://wagtail.org/roadmap). +release in the form of a request for comments (RFC) to +[Wagtail's RFCs repository](https://github.com/wagtail/rfcs). Anyone is welcome +and encouraged to comment on the RFC. After the RFC is approved by the +[Wagtail core team](https://wagtail.org/core-team/), the roadmap update will be +available on [wagtail.org/roadmap](https://wagtail.org/roadmap). #### Phase two: development diff --git a/docs/releases/upgrading.md b/docs/releases/upgrading.md index 4517395b30..97c1c59b9a 100644 --- a/docs/releases/upgrading.md +++ b/docs/releases/upgrading.md @@ -10,7 +10,8 @@ For dates of past and upcoming releases and support periods, see [Release schedu ## Required reading -If it’s your first time doing an upgrade, it is useful to read the guide on [](../contributing/release_process). +If it’s your first time doing an upgrade, it is highly recommended to read the +guide on [](../contributing/release_process). ## Upgrade process @@ -40,7 +41,7 @@ PYTHONWARNINGS=always pytest tests --capture=no Resolve any deprecation warnings with your current version of Wagtail before continuing the upgrade process. -Third party packages might use deprecated APIs in order to support multiple versions of Wagtail, so deprecation warnings in packages you’ve installed don’t necessarily indicate a problem. If a package doesn’t support the latest version of Wagtail, consider raising an issue or sending a pull request for it. +Third party packages might use deprecated APIs in order to support multiple versions of Wagtail, so deprecation warnings in packages you’ve installed don’t necessarily indicate a problem. If a package doesn’t support the latest version of Wagtail, consider raising an issue or sending a pull request to that package. ### Preparing for the upgrade @@ -48,7 +49,8 @@ After resolving the deprecation warnings, you should read the [release notes](.. Pay particular attention to the upgrade considerations sections (which describe any backwards-incompatible changes) to get a clear idea of what will be needed for a successful upgrade. -Also read the [Compatible Django / Python versions](compatible_django_python_versions) table below, as they may need upgrading first. +Also read the [](compatible_django_python_versions) table below, as they may +need upgrading first. Before continuing with the upgrade, make a backup of your database. @@ -56,7 +58,7 @@ Before continuing with the upgrade, make a backup of your database. To upgrade: -- Update the `wagtail` line in your project's `requirements.txt` file to specify the latest patch release of the version you wish to install. For example, to upgrade to version 6.3.x, the line should read: +- Update the `wagtail` line in your project's `requirements.txt` file (or the equivalent, such as `pyproject.toml`) to specify the latest patch release of the version you wish to install. For example, to upgrade to version 6.3.x, the line should read: wagtail>=6.3,<6.4