Erik Ritter 4fe63d5833 Infer SQL_LAB QuerySource from referrer (#9181) | il y a 4 ans | |
---|---|---|
.. | ||
email_templates | il y a 4 ans | |
Dockerfile.from_local_tarball | il y a 4 ans | |
Dockerfile.from_svn_tarball | il y a 4 ans | |
Dockerfile.make_docs | il y a 4 ans | |
Dockerfile.make_tarball | il y a 4 ans | |
README.md | il y a 4 ans | |
from_tarball_entrypoint.sh | il y a 4 ans | |
make_docs.sh | il y a 4 ans | |
make_docs_entrypoint.sh | il y a 4 ans | |
make_tarball.sh | il y a 4 ans | |
make_tarball_entrypoint.sh | il y a 4 ans | |
send_email.py | il y a 4 ans | |
set_release_env.sh | il y a 4 ans | |
test_run_tarball.sh | il y a 4 ans |
Until things settle and we create scripts that streamline this, you'll probably want to run these commands manually and understand what they do prior to doing so.
For coordinating on releases, on operational topics that require more
synchronous communications, we recommend using the #apache-releases
channel
on the Superset Slack. People crafting releases and those interested in
partaking in the process should join the channel.
First you need to setup a few things. This is a one-off and doesn't need to be done at every release.
# Create PGP Key, and use your @apache.org email address
gpg --gen-key
# Checkout ASF dist repo
svn checkout https://dist.apache.org/repos/dist/dev/incubator/superset/ ~/svn/superset_dev
svn checkout https://dist.apache.org/repos/dist/release/incubator/superset/ ~/svn/superset
cd ~/svn/superset
# Add your GPG pub key to KEYS file. Replace "Maxime Beauchemin" with your name
export SUPERSET_PGP_FULLNAME="Maxime Beauchemin"
(gpg --list-sigs "${SUPERSET_PGP_FULLNAME}" && gpg --armor --export "${SUPERSET_PGP_FULLNAME}" ) >> KEYS
# Commit the changes
svn commit -m "Add PGP keys of new Superset committer"
As the vote process takes a minimum of 72h (community vote) + 72h (IPMC) vote,
often stretching over several weeks calendar time if votes don't pass, chances are
the same terminal session won't be used for crafting the release candidate and the
final release. Therefore, it's a good idea to do the following every time you
work on a new phase of the release process to make sure you aren't releasing
the wrong files/using wrong names. There's a script to help you set correctly all the
necessary environment variables. Change your current directory to superset/RELEASING
# usage: . set_release_env.sh <SUPERSET_VERSION_RC> <PGP_KEY_FULLNAME>
# example: . set_release_env.sh 0.35.2rc1 myid@apache.org
The script will output the exported variables. Here's example for 0.35.2rc2:
-------------------------------
Set Release env variables
SUPERSET_PGP_FULLNAME=myid@apache.org
SUPERSET_VERSION_RC=0.35.2rc1
SUPERSET_GITHUB_BRANCH=0.35
SUPERSET_TMP_ASF_SITE_PATH=/tmp/incubator-superset-site-0.35.2
SUPERSET_RELEASE_RC=apache-superset-incubating-0.35.2rc1
SUPERSET_RELEASE_RC_TARBALL=apache-superset-incubating-0.35.2rc1-source.tar.gz
SUPERSET_RC=1
SUPERSET_CONFIG_PATH=/Users/ville/superset/superset_config.py
SUPERSET_RELEASE=apache-superset-incubating-0.35.2
SUPERSET_RELEASE_TARBALL=apache-superset-incubating-0.35.2-source.tar.gz
SUPERSET_VERSION=0.35.2
-------------------------------
When crafting a new minor or major release we create a branch named with the release MAJOR.MINOR version (on this example 0.35). This new branch will hold all PATCH and release candidates that belong to the MAJOR.MINOR version.
The MAJOR.MINOR branch is normally a "cut" from a specific point in time from the master branch. Then (if needed) apply all cherries that will make the PATCH
Next update the CHANGELOG.md
with all the changes that are included in the release. Make sure you have
set your GITHUB_TOKEN environment variable.
# will overwrites the local CHANGELOG.md, somehow you need to merge it in
github-changes -o apache -r incubator-superset --token $GITHUB_TOKEN -b $SUPERSET_GITHUB_BRANCH
Then, in UPDATING.md
, a file that contains a list of notifications around
deprecations and upgrading-related topics,
make sure to move the content now under the Next Version
section under a new
section for the new release.
Finally bump the version number on superset-frontend/package.json
(replace with whichever version is being released excluding the RC version):
"version": "0.35.2"
Commit the change with the version number, then git tag the version with the release candidate and push to the branch
The first step of preparing an Apache Release is packaging a release candidate to be voted on. Make sure you have correctly prepared and tagged the ready to ship release on Superset's repo (MAJOR.MINOR branch), the following script will clone the tag and create a signed source tarball from it:
# make_tarball will use the previously set environment variables
# you can override by passing arguments: make_tarball.sh <SUPERSET_VERSION> <SUPERSET_VERSION_RC> "<PGP_KEY_FULLNAME>"
./make_tarball.sh
Note that make_tarball.sh
:
$HOME/svn/superset_dev
.
This can be overriden by setting SUPERSET_SVN_DEV_PATH
environment var to a different svn dev directorypackage.json
version number and fails if it's not correctly setTo build and run the local copy of the recently created tarball:
# Build and run a release candidate tarball
./test_run_tarball.sh local
# you should be able to access localhost:5001 on your browser
# login using admin/admin
Now let's ship this RC into svn's dev folder
cd ~/svn/superset_dev/
svn add ${SUPERSET_VERSION_RC}
svn commit -m "Release ${SUPERSET_VERSION_RC}"
To build and run the recently created tarball from SVN:
# Build and run a release candidate tarball
./test_run_tarball.sh
# you should be able to access localhost:5001 on your browser
# login using admin/admin
Now you're ready to start the [VOTE] thread. Here's an example of a previous release vote thread: https://lists.apache.org/thread.html/e60f080ebdda26896214f7d3d5be1ccadfab95d48fbe813252762879@
To easily send a voting request to Superset community, still on the superset/RELEASING
directory:
# Note: use Superset's virtualenv
(venv)$ python send_email.py vote_pmc
The script will interactively ask for extra information so it can authenticate on the Apache Email Relay. The release version and release candidate number are fetched from the previously set environment variables.
Sender email (ex: user@apache.org): your_apache_email@apache.org
Apache username: your_apache_user
Apache password: your_apache_password
Once 3+ binding votes (by PMC members) have been cast and at least 72 hours have past, you can post a [RESULT] thread: https://lists.apache.org/thread.html/50a6b134d66b86b237d5d7bc89df1b567246d125a71394d78b45f9a8@%3Cdev.superset.apache.org%3E
To easily send the result email, still on the superset/RELEASING
directory:
# Note: use Superset's virtualenv
(venv)$ python send_email.py result_pmc
The script will interactively ask for extra information needed to fill out the email template. Based on the voting description, it will generate a passing, non passing or non conclusive email. here's an example:
Sender email (ex: user@apache.org): your_apache_email@apache.org
Apache username: your_apache_user
Apache password: your_apache_password
A List of people with +1 binding vote (ex: Max,Grace,Krist): Daniel,Alan,Max,Grace
A List of people with +1 non binding vote (ex: Ville): Ville
A List of people with -1 vote (ex: John):
Following the result thread, yet another [VOTE] thread should be started at general@incubator.apache.org.
To easily send the voting request to Apache community, still on the superset/RELEASING
directory:
# Note: use Superset's virtualenv
(venv)$ python send_email.py vote_ipmc
Once 3+ binding votes (by IPMC members) have been cast and at least 72 hours have past, you can post a [RESULT] thread
To easily send the result email, still on the superset/RELEASING
directory:
# Note: use Superset's virtualenv
(venv)$ python send_email.py result_ipmc
Again, the script will interactively ask for extra information needed to fill out the email template. Based on the voting description, it will generate a passing, non passing or non conclusive email. here's an example:
Sender email (ex: user@apache.org): your_apache_email@apache.org
Apache username: your_apache_user
Apache password: your_apache_password
A List of people with +1 binding vote (ex: Alan, Justin): Alan,Jeff,
A List of people with +1 non binding vote (ex: Ville):
A List of people with -1 vote (ex: John):
https://www.apache.org/info/verification.html
Upon a successful vote (community AND IPMC), you'll have to copy the folder into the non-"dev/" folder.
cp -r ~/svn/superset_dev/${SUPERSET_VERSION_RC}/ ~/svn/superset/${SUPERSET_VERSION}/
cd ~/svn/superset/
# Rename the RC (0.34.1rc1) to the actual version being released (0.34.1)
for f in ${SUPERSET_VERSION}/*; do mv "$f" "${f/${SUPERSET_VERSION_RC}/${SUPERSET_VERSION}}"; done
svn add ${SUPERSET_VERSION}
svn commit -m "Release ${SUPERSET_VERSION}"
Then tag the final release:
# Go to the root directory of the repo, e.g. `~/src/incubator-superset`
cd ~/src/incubator-superset/
# make sure you're on the correct branch (e.g. 0.34)
git branch
# Create the release tag
git tag -f ${SUPERSET_VERSION}
Now that we have a final Apache source release we need to open a pull request on Superset
with the changes on CHANGELOG.md
and UPDATING.md
.
From the root of the repo running ./pypi_push.sh will build the Javascript bundle and echo the twine command allowing you to publish to PyPI. You may need to ask a fellow committer to grant you access to it if you don't have access already. Make sure to create an account first if you don't have one, and reference your username while requesting access to push packages.
Once it's all done, an [ANNOUNCE] thread announcing the release to the dev@ mailing list is the final step.
# Note use Superset's virtualenv
(venv)$ python send_email.py announce
Every once in a while we want to compile the documentation and publish it. Here's how to do it.
./make_docs.sh
Superset documentation site is ready at http://localhost:5002
$ cd /tmp/incubator-superset-site-${SUPERSET_VERSION}
$ git add .
$ git commit -a -m "New doc version ${SUPERSET_VERSION}"
$ git push origin asf-site