This is an automated email from the ASF dual-hosted git repository.
raulcd pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/arrow.git
The following commit(s) were added to refs/heads/main by this push:
new 6c06b37434 GH-40551: [Release][Docs] Improve documentation for patch
Release process (#40552)
6c06b37434 is described below
commit 6c06b37434f865e52c69951ad9de40b36895be0d
Author: Raúl Cumplido <[email protected]>
AuthorDate: Tue Mar 19 09:31:48 2024 +0100
GH-40551: [Release][Docs] Improve documentation for patch Release process
(#40552)
### Rationale for this change
Improve our current documentation on process to follow for identifying
issues for patch releases and how to ask for a patch release.
### What changes are included in this PR?
Documentation
### Are these changes tested?
I will run preview-docs
### Are there any user-facing changes?
No
* GitHub Issue: #40551
Authored-by: Raúl Cumplido <[email protected]>
Signed-off-by: Raúl Cumplido <[email protected]>
---
docs/source/developers/release.rst | 39 +++++++++++++++++++++++++++++++++++++-
1 file changed, 38 insertions(+), 1 deletion(-)
diff --git a/docs/source/developers/release.rst
b/docs/source/developers/release.rst
index 1ecf747e36..09608f2834 100644
--- a/docs/source/developers/release.rst
+++ b/docs/source/developers/release.rst
@@ -92,15 +92,52 @@ Ensure a major version milestone for a follow up release is
created on GitHub. T
automatically be used by our merge script as the new version for issues closed
when
the maintenance branch is created.
+Patch Releases
+==============
+
+We usually create patch releases once a major breaking issue has been
identified.
+Issues that are identified as major breaking issues can be security fixes,
broken packages
+for specific builds and others.
+
+Any developer can ask for a patch release to be generated sending an email to
the
+`Arrow development mailing-list <https://arrow.apache.org/community/>`__ with
the reason
+of why a new release is necessary.
+If there is consensus and there is a Release Manager willing to take the
effort to create
+the release a patch release can be created.
+
+Committers can tag issues that should be included on the next patch release
using the
+`backport-candidate` label. Is the responsability of the author or the
committer to add the
+label to the issue to help the Release Manager identify the issues that should
be backported.
+
+If a specific issue is identified as the reason to create a patch release the
Release Manager
+should validate that, at least, this issue is correctly tagged and included in
the patch release.
+
+Be sure to go through on the following checklist:
+
+#. Create milestone
+#. Create maintenance branch
+#. Include issue that was requested as requiring new patch release
+#. Add new milestone to issues with `backport-candidate` label
+#. cherry-pick issues into maintenance branch
+
Creating a Release Candidate
============================
These are the different steps that are required to create a Release Candidate.
-For the initial Release Candidate, we will create a maintenance branch from
main.
+For the initial Release Candidate on a major release, we will create a
maintenance
+branch from main.
+
Follow up Release Candidates will update the maintenance branch by
cherry-picking
specific commits.
+For the the initial Release Candidate for a minor or a patch release we will
create
+a maintenance branch from the previous corresponding release. For example,
+for a 15.0.1 patch we will create a maint-15.0.1 branch from maint-15.0.0 and
for
+a maint-15.0.2 we will create it from maint-15.0.1. Once the maintenance
branch is
+created we will update the created maintenance branch by cherry-picking
specific
+commits.
+
We have implemented a Feature Freeze policy between Release Candidates.
This means that, in general, we should only add bug fixes between Release
Candidates.
In rare cases, critical features can be added between Release Candidates, if
