This is an automated email from the ASF dual-hosted git repository.
alamb pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/arrow-rs.git
The following commit(s) were added to refs/heads/master by this push:
new 28154c3 Update dev/release/README for master releases, remove
supporting scripts (#1143)
28154c3 is described below
commit 28154c3df8bf436a63a9b34a72b3982fdeac88bb
Author: Andrew Lamb <[email protected]>
AuthorDate: Thu Jan 13 13:14:39 2022 -0500
Update dev/release/README for master releases, remove supporting scripts
(#1143)
* Update dev/release/README for master releases
* remove cherry pick script
---
dev/release/README.md | 113 +++----------------------------
dev/release/cherry-pick-pr.py | 154 ------------------------------------------
2 files changed, 10 insertions(+), 257 deletions(-)
diff --git a/dev/release/README.md b/dev/release/README.md
index ef379a5..a9603f5 100644
--- a/dev/release/README.md
+++ b/dev/release/README.md
@@ -19,33 +19,15 @@
# Release Process
-## Branching
+## Overview
-Arrow maintains two branches: `active_release` and `master`.
+We try to release a new version of Arrow every two weeks. This cadence
balances getting new features into arrow without overwhelming downstream
projects with too frequent changes.
-- All new PRs are created and merged against `master`
-- All versions are created from the `active_release` branch
-- Once merged to master, changes are "cherry-picked" (via a hopefully soon to
be automated process), to the `active_release` branch based on the judgement of
the original PR author and maintainers.
-
-- We do not merge breaking api changes, as defined in [Rust RFC
1105](https://github.com/rust-lang/rfcs/blob/master/text/1105-api-evolution.md)
to the `active_release` branch. Instead, they are merged to the `master` branch
and included in the next major release.
-
-Please see the [original
proposal](https://docs.google.com/document/d/1tMQ67iu8XyGGZuj--h9WQYB9inCk6c2sL_4xMTwENGc/edit?ts=60961758)
document the rational of this change.
-
-## Release Branching
-
-We aim to release every other week from the `active_release` branch.
-
-Every other week, a maintainer proposes a minor (e.g. `4.1.0` to `4.2.0`) or
patch (e.g `4.1.0` to `4.1.1`) release, depending on changes to the
`active_release` in the previous 2 weeks, following the process below.
-
-If this release is approved by at least three PMC members, that tarball is
uploaded to the official apache distribution sites, a new version from that
tarball is released to crates.io later in the week.
-
-The overall Apache Arrow in general does synchronized major releases every
three months. The Rust implementation aims to do its major releases in the same
time frame.
+If any code has been merged to master that has a breaking API change, as
defined in [Rust RFC
1105](https://github.com/rust-lang/rfcs/blob/master/text/1105-api-evolution.md),
the major version number incremented changed (e.g. `7.0.0` to `8.0.0`).
Otherwise the new minor version incremented (e.g. `7.0.0` to `7.1.0`).
# Release Mechanics
-This directory contains the scripts used to manage an Apache Arrow Release.
-
-# Process Overview
+## Process Overview
As part of the Apache governance model, official releases consist of
signed source tarballs approved by the PMC.
@@ -53,12 +35,6 @@ signed source tarballs approved by the PMC.
We then use the code in the approved source tarball to release to
crates.io, the Rust ecosystem's package manager.
-## Branching
-
-# Release Preparation
-
-# Change Log
-
We create a `CHANGELOG.md` so our users know what has been changed between
releases.
The CHANGELOG is created automatically using
@@ -67,47 +43,16 @@ The CHANGELOG is created automatically using
This script creates a changelog using github issues and the
labels associated with them.
-## CHANGELOG for maintenance releases
-
-At the time of writing, the `update_change_log.sh` script does not work well
with branches as it seems to intermix issues that were resolved in master.
+## Prepare CHANGELOG and version:
-To generate a bare bones CHANGELOG for maintenance releases, you can use a
command similar to the following to get all changes between 5.0.0 and the
active_release.
+Now prepare a PR to update `CHANGELOG.md` and versions on `master` to reflect
the planned release.
-```shell
-git log --pretty=oneline 5.0.0..apache/active_release
-```
-
-This command will make markdown links that work when rendered outside of
github:
-
-```shell
-git log --pretty=oneline 5.1.0..apache/active_release | sed -e
's|\(^[0-9a-f]*\) |* [\1](https://github.com/apache/arrow-rs/commit/\1) |' |
sed -e 's|#\([0-9]*\)|[#\1](https://github.com/apache/arrow-rs/pull/\1)|g'
-```
-
-# Mechanics of creating a release
-
-## Prepare the release branch and tags
-
-First, ensure that `active_release` contains the content of the desired
release. For minor and patch releases, no additional steps are needed.
-
-To prepare for _a major release_, change `active release` to point at the
latest `master` with commands such as:
-
-```
-git checkout active_release
-git fetch apache
-git reset --hard apache/master
-git push -f
-```
-
-### Update CHANGELOG.md + Version
-
-Now prepare a PR to update `CHANGELOG.md` and versions on `active_release`
branch to reflect the planned release.
-
-See [#298](https://github.com/apache/arrow-rs/pull/298) for an example.
+See [#1141](https://github.com/apache/arrow-rs/pull/1141) for an example.
Here are the commands that could be used to prepare the 5.1.0 release:
```bash
-git checkout active_release
+git checkout master
git pull
git checkout -b make-release
@@ -138,7 +83,7 @@ Using a string such as `4.0.1` as the `<version>`, create
and push the tag thusl
```shell
git fetch apache
-git tag <version> apache/active_release
+git tag <version> apache/master
# push tag to apache
git push apache <version>
```
@@ -198,7 +143,7 @@ The vote will be open for at least 72 hours.
For the release to become "official" it needs at least three PMC members to
vote +1 on it.
-#### Verifying Release Candidates
+## Verifying release candidates
The `dev/release/verify-release-candidate.sh` is a script in this repository
that can assist in the verification process. Run it like:
@@ -246,41 +191,3 @@ following commands
(cd parquet && cargo publish)
(cd parquet_derive && cargo publish)
```
-
-# Backporting
-
-As of the time of writing, backporting to `active_release` done semi-manually.
-
-_Note_: Since minor releases will be automatically picked up by other CI
systems, it is CRITICAL to only cherry pick commits that are API compatible --
that is that do not require any code changes in crates that rely on arrow. API
changes are released with the next major version.
-
-Step 1: Pick the commit to cherry-pick.
-
-Step 2: Create cherry-pick PR to active_release
-
-Step 3a: If CI passes, merge cherry-pick PR
-
-Step 3b: If CI doesn't pass or some other changes are needed, the PR should be
reviewed / approved as normal prior to merge
-
-For example, to backport `b2de5446cc1e45a0559fb39039d0545df1ac0d26` to
active_release, you could use the following command
-
-```shell
-git clone [email protected]:apache/arrow-rs.git /tmp/arrow-rs
-
-CHERRY_PICK_SHA=b2de5446cc1e45a0559fb39039d0545df1ac0d26
ARROW_GITHUB_API_TOKEN=$ARROW_GITHUB_API_TOKEN CHECKOUT_ROOT=/tmp/arrow-rs
python3 dev/release/cherry-pick-pr.py
-```
-
-## Labels
-
-There are two labels that help keep track of backporting:
-
-1. [`cherry-picked`](https://github.com/apache/arrow-rs/labels/cherry-picked)
for PRs that have been cherry-picked/backported to `active_release`
-2.
[`release-cherry-pick`](https://github.com/apache/arrow-rs/labels/release-cherry-pick)
for the PRs that are the cherry pick to `active_release`
-
-You can find candidates to cherry pick using [this
filter](https://github.com/apache/arrow-rs/pulls?q=is%3Apr+is%3Aclosed+-label%3Arelease-cherry-pick+-label%3Acherry-picked)
-
-## Rationale for creating PRs on cherry picked PRs:
-
-1. PRs are a natural place to run the CI tests to make sure there are no
logical conflicts
-2. PRs offer a place for the original author / committers to comment and say
it should/should not be backported.
-3. PRs offer a way to make cleanups / fixups and approve (if needed) for non
cherry pick PRs
-4. There is an additional control / review when the candidate release is
created
diff --git a/dev/release/cherry-pick-pr.py b/dev/release/cherry-pick-pr.py
deleted file mode 100755
index 2886a0d..0000000
--- a/dev/release/cherry-pick-pr.py
+++ /dev/null
@@ -1,154 +0,0 @@
-#!/usr/bin/python3
-##############################################################################
-# Licensed to the Apache Software Foundation (ASF) under one
-# or more contributor license agreements. See the NOTICE file
-# distributed with this work for additional information
-# regarding copyright ownership. The ASF licenses this file
-# to you under the Apache License, Version 2.0 (the
-# "License"); you may not use this file except in compliance
-# with the License. You may obtain a copy of the License at
-#
-# http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing,
-# software distributed under the License is distributed on an
-# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-# KIND, either express or implied. See the License for the
-# specific language governing permissions and limitations
-# under the License.
-##############################################################################
-
-# This script is designed to create a cherry pick PR to a target branch
-#
-# Usage: python3 cherry_pick_pr.py
-#
-# To test locally:
-#
-# git clone [email protected]:apache/arrow-rs.git /tmp/arrow-rs
-#
-# pip3 install PyGithub
-# ARROW_GITHUB_API_TOKEN=<..>
-# CHECKOUT_ROOT=<path>
-# CHERRY_PICK_SHA=<sha> python3 cherry-pick-pr.py
-#
-import os
-import sys
-import six
-import subprocess
-
-from pathlib import Path
-
-TARGET_BRANCH = 'active_release'
-TARGET_REPO = 'apache/arrow-rs'
-
-p = Path(__file__)
-
-# Use github workspace if specified
-repo_root = os.environ.get("CHECKOUT_ROOT")
-if repo_root is None:
- print("arrow-rs checkout must be supplied in CHECKOUT_ROOT environment")
- sys.exit(1)
-
-print("Using checkout in {}".format(repo_root))
-
-token = os.environ.get('ARROW_GITHUB_API_TOKEN', None)
-if token is None:
- print("GITHUB token must be supplied in ARROW_GITHUB_API_TOKEN environmet")
- sys.exit(1)
-
-new_sha = os.environ.get('CHERRY_PICK_SHA', None)
-if new_sha is None:
- print("SHA to cherry pick must be supplied in CHERRY_PICK_SHA environment")
- sys.exit(1)
-
-
-# from merge_pr.py from arrow repo
-def run_cmd(cmd):
- if isinstance(cmd, six.string_types):
- cmd = cmd.split(' ')
- try:
- output = subprocess.check_output(cmd)
- except subprocess.CalledProcessError as e:
- # this avoids hiding the stdout / stderr of failed processes
- print('Command failed: %s' % cmd)
- print('With output:')
- print('--------------')
- print(e.output)
- print('--------------')
- raise e
-
- if isinstance(output, six.binary_type):
- output = output.decode('utf-8')
-
- return output
-
-
-os.chdir(repo_root)
-new_sha_short = run_cmd("git rev-parse --short {}".format(new_sha)).strip()
-new_branch = 'cherry_pick_{}'.format(new_sha_short)
-
-
-def make_cherry_pick():
- if os.environ.get('GITHUB_SHA', None) is not None:
- print("Running on github runner, setting email/username")
- run_cmd(['git', 'config', 'user.email', '[email protected]'])
- run_cmd(['git', 'config', 'user.name', 'Arrow-RS Automation'])
-
- #
- # Create a new branch from active_release
- # and cherry pick to there.
- #
-
- print("Creating cherry pick from {} to {}".format(
- new_sha_short, new_branch
- ))
-
- # The following tortured dance is required due to how the github
- # actions/checkout works (it doesn't pull other branches and pulls
- # only one commit back)
-
- # pull 10 commits back so we can get the proper cherry pick
- # (probably only need 2 but 10 must be better, right?)
- run_cmd(['git', 'fetch', '--depth', '10', 'origin', 'master'])
- run_cmd(['git', 'fetch', 'origin', 'active_release'])
- run_cmd(['git', 'checkout', '-b', new_branch])
- run_cmd(['git', 'reset', '--hard', 'origin/active_release'])
- run_cmd(['git', 'cherry-pick', new_sha])
- run_cmd(['git', 'push', '-u', 'origin', new_branch])
-
-
-
-def make_cherry_pick_pr():
- from github import Github
- g = Github(token)
- repo = g.get_repo(TARGET_REPO)
-
- release_cherry_pick_label = repo.get_label('release-cherry-pick')
- cherry_picked_label = repo.get_label('cherry-picked')
-
- # Default titles
- new_title = 'Cherry pick {} to active_release'.format(new_sha)
- new_commit_message = 'Automatic cherry-pick of {}\n'.format(new_sha)
-
- # try and get info from github api
- commit = repo.get_commit(new_sha)
- for orig_pull in commit.get_pulls():
- new_commit_message += '* Originally appeared in {}: {}\n'.format(
- orig_pull.html_url, orig_pull.title)
- new_title = 'Cherry pick {} to active_release'.format(orig_pull.title)
- orig_pull.add_to_labels(cherry_picked_label)
-
- pr = repo.create_pull(title=new_title,
- body=new_commit_message,
- base='refs/heads/active_release',
- head='refs/heads/{}'.format(new_branch),
- maintainer_can_modify=True,
- )
-
- pr.add_to_labels(release_cherry_pick_label)
-
- print('Created PR {}'.format(pr.html_url))
-
-
-make_cherry_pick()
-make_cherry_pick_pr()
