Skip to content

Latest commit

 

History

History
93 lines (73 loc) · 2.95 KB

RELEASING.md

File metadata and controls

93 lines (73 loc) · 2.95 KB
Raw

Refresh documentation website

Every once in a while we want to compile the documentation and publish it. Here's how to do it.

# install doc dependencies
pip install -r docs/requirements.txt

# build the docs
python setup.py build_sphinx

# copy html files to temp folder
cp -r docs/_build/html/ /tmp/tmp_superset_docs/

# clone the docs repo
cd ~/
git clone https://git-wip-us.apache.org/repos/asf/incubator-superset-site.git

# copy
cp -r /tmp/tmp_superset_docs/ ~/incubator-superset-site.git/

# commit and push to `asf-site` branch
cd ~/incubator-superset-site.git/
git checkout asf-site
git add .
git commit -a -m "New doc version"
git push origin master

Publishing a PyPI release

We create a branch that goes along each minor release 0.24 and micro releases get corresponding tags as in 0.24.0. Git history should never be altered in release branches. Bug fixes and security-related patches get cherry-picked (usually from master) as in git cherry-pick -x {SHA}.

Following a set of cherries being picked, a release can be pushed to PyPI as follows:

# branching off of master
git checkout -b 0.25

# cherry-picking a SHA
git cherry-pick -x f9d85bd2e1fd9bc233d19c76bed09467522b968a
# repeat with other SHAs, don't forget the -x

# source of thruth for release numbers live in package.json
vi superset/assets/package.json
# hard code release in file, commit to the release branch
git commit -a -m "0.25.0"

# create the release tag in the release branch
git tag 0.25.0
git push apache 0.25 --tags

# check travis to confirm the build succeeded as
# you shouldn't assume that a clean cherry will be clean
# when landing on a new sundae

# compile the JS, and push to pypi
# to run this part you'll need a pypi account and rights on the
# superset package. Committers that want to ship releases
# should have this access.
# You'll also need a `.pypirc` as specified here:
# http://peterdowns.com/posts/first-time-with-pypi.html
./pypi_push.sh

# publish an update to the CHANGELOG.md for the right version range
# looking the latest CHANGELOG entry for the second argument
./gen_changelog.sh 0.22.1 0.25.0
# this will overwrite the CHANGELOG.md with only the version range
# so you'll want to copy paste that on top of the previous CHANGELOG.md
# open a PR against `master`

In the future we'll start publishing release candidates for minor releases only, but typically not for micro release. The process will be similar to the process described above, expect the tags will be formatted 0.25.0rc1, 0.25.0rc2, ..., until consensus is reached.

We should also have a Github PR label process to target the proper release, and tooling helping keeping track of all the cherries and target versions.

For Apache releases, the process will be a bit heavier and should get documented here. There will be extra steps for signing the binaries, with a PGP key and providing MD5, Apache voting, as well as publishing to Apache's SVN repository. View the ASF docs for more information.