-
Notifications
You must be signed in to change notification settings - Fork 54
Home
-
Create a release branch (on GitHub) for each new major or minor release, i.e.
3.1_rel
onto which all the3.1.x
releases will live. -
Clone repo and checkout release branch, on that release branch in your local clone:
- In
setup.py
changedefault_version
to be the tag of the release you are creating. i.e.3.1.0
- Similarly in
docs/sources/conf.py
changeversion
andrelease
to the same tag. - Commit and push these changes to github (on the release branch)
- In
-
On github create the new release (on the release branch). This will create the
3.1.0
tag. -
git pull
in your local repo to bring down the new release tag and check out the release branch i.e.git co 3.1_rel
.At this point (on the release branch) a
git describe --tags --dirty
should show the release tag (3.1.0
) and nothing else (not3.1.0rc0-dirty
, etc.) -
Create the pypi package
Note that pypi will not allow you to replace a package with the same version number (even if you delete the old one). So keep that in mind before uploading a package to either the main or test site.
- Start from a clean conda env:
conda remove --name ccsi-foqus --all -y # remove any old conda env conda create --name ccsi-foqus python=3.7 -y # create an entirely new conda env conda activate ccsi-foqus
- In a clean repo on the release tag, get set up to build package:
git clone git@github.com:CCSI-Toolset/FOQUS.git cd FOQUS git co 3.1.0 git clean -dfx # If using an existing repo pip install --upgrade setuptools wheel twine
- Build and push to test pypi
pip install -r requirements.txt # or pip install -e . python setup.py sdist bdist_wheel # bdist_wininst on Windows # Check for any old builds in ./dist/ twine upload --repository-url https://test.pypi.org/legacy/ dist/* # Upload to test pypi
- Test package from test PyPi
pip install -i https://test.pypi.org/simple/ --extra-index-url https://pypi.org/simple ccsi-foqus foqus.py # Start app
- Push to real PyPi
twine upload dist/*
- Start from a clean conda env:
-
git co master
and changesetup.py
anddocs/sources/conf.py
in the same places as above, but now on master change to the next "dev" version, i.e.3.1.0dev
to3.2.0dev
. Stage, check-in these changes and then tag them with a new "dev" tag: i.e.git tag 3.2.0dev
, then push up to github (git push --tags
or the tag won't get pushed up.)At this point (on master) a
git describe --tags --dirty
should show the dev tag (3.2.0dev
) and nothing else (not3.2.0dev-dirty
, etc.) -
Update readthedocs so that it builds from the new tag and uses that as the default version to display.
-
Announce the release.