You are viewing a plain text version of this content. The canonical link for it is here.
Posted to github@arrow.apache.org by GitBox <gi...@apache.org> on 2022/06/07 18:44:49 UTC

[GitHub] [arrow] jorisvandenbossche commented on a diff in pull request #13308: ARROW-16666: [Docs][Release] Update release guide to specify new workflow and feature freeze

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


##########
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:
   What is the goal / use of the "release branch", in addition to the "maintenance branch"? 
   
   (this might be a question with the current workflow, not so much the changes in this PR)



##########
docs/source/developers/release.rst:
##########
@@ -87,12 +87,55 @@ These are the different steps that are required to create a release candidate.
     # Curate the release
     # The end of the generated report shows the jira tickets with wrong version number assigned.
     archery release curate <version>
-    
-    # Checkout release branch
-    # Use master for major releases
-    git checkout -b release-4.0.0 master
-    # Use maintenance branches like maint-4.0.x for patch releases
-    git checkout -b release-4.0.1 maint-4.0.x
+
+
+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 will only add 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 branches:
+
+.. 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

Review Comment:
   We could also term it as "maint-X.0.0", as it will always be like that? (although not sure if that reads any clearer)
   
   (which also makes me wonder: is this name fixed? Something like "maint-X.x" (eg maint-9.x, or maint-9.0.x) would be clearer I think)



##########
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
     
-    # Checkout release branch
-    # Use master for major releases
-    git checkout -b release-4.0.0 master
-    # Use maintenance branches like maint-4.0.x for patch releases
-    git checkout -b release-4.0.1 maint-4.0.x
-    
-    # Create branch for the release candidate and place the necessary commits then create git tag
+    # Create branch for the Release Candidate and place the necessary commits then create git tag

Review Comment:
   What are typically the "necessary commits" that are not yet already cherry-picked on the maintenance branch?



-- 
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: github-unsubscribe@arrow.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org