raulcd commented on code in PR #13308:
URL: https://github.com/apache/arrow/pull/13308#discussion_r892078007


##########
docs/source/developers/release.rst:
##########
@@ -85,26 +85,78 @@ These are the different steps that are required to create a 
release candidate.
     source dev/release/setup-gpg-agent.sh
     
     # Curate the release
-    # The end of the generated report shows the jira tickets with wrong 
version number assigned.
+    # The end of the generated report shows the JIRA tickets with wrong 
version number assigned.
     archery release curate <version>
+
+
+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 
master.
+Follow up Release Candidates will update the maintenance branch 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
+there is community consensus.
+
+Create or update the corresponding maintenance branch
+-----------------------------------------------------
+
+.. tab-set::
+
+   .. tab-item:: Initial Release Candidate
+
+      .. code-block::
+
+            # Execute the following from an up to date master branch.
+            # This will create a branch locally called maint-X.Y.Z
+            # X.Y.Z corresponds with the Major, Minor and Patch version number
+            # of the release respectively. As an example 9.0.0
+            archery release --jira-cache /tmp/jiracache cherry-pick X.Y.Z 
--execute
+            # Push the maintenance branch to the remote repository
+            git push -u apache maint-X.Y.Z
+
+   .. tab-item:: Follow up Release Candidates
+
+      .. code-block::
+
+            # First run in dry-mode to see which commits will be cherry-picked.
+            # If there are commits that we don't want to get applied ensure 
the version on
+            # JIRA is set to the following release.
+            archery release --jira-cache /tmp/jiracache cherry-pick X.Y.Z 
--continue
+            # Update the maintenance branch with the previous commits
+            archery release --jira-cache /tmp/jiracache cherry-pick X.Y.Z 
--continue --execute
+            # Push the updated maintenance branch to the remote repository
+            git push -u apache maint-X.Y.Z
+
+Create the Release Candidate and release branch from the updated maintenance 
branch
+-----------------------------------------------------------------------------------
+
+.. code-block::
+
+    # Create the release branch from the updated maintenance branch.
+    git checkout -b release-X.Y.Z maint-X.Y.Z

Review Comment:
   I am not entirely sure. I think that working with the maintenance branch as 
base and with a release candidate branch for the minor changes/changelogs/etc, 
should be enough in order to do the verification. @kszucs do you think the 
release branch is necessary at this point? I can't find any script where we are 
using it specifically.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to