textX release process¶
For the background see here.
- We are using semantic versioning and a standard format to keep changelogs (see CHANGELOG.md).
- We develop features on feature branches. Feature branches are named
- We fix bugs on bugfix branches named as
- We have a branch for the upcoming major release --
next-release(red in the picture bellow).
- If the feature is backward incompatible (BIC) the PR is made against the
next-releasebranch (not against the
- If the feature is backward compatible PR is made against the
Unreleasedsection in the changelog on the
masterbranch will never have any BIC change. All BIC changes should go to the changelog on the
- We constantly merge
next-releasebranch is the latest and greatest version with all finished features applied.
- When the time for minor release come we follow textX release checklist defined bellow.
- When the time for major release come we merge
masterand follow textX release checklist defined bellow.
textX release checklist¶
- If minor/major version increase, create maintenance/support branch from the
current master. The name is
- Create a temporary branch for preparing the next release called
release-preparationand switch to that branch.
- Update version in the
- Update CHANGELOG (create new section for the release, update github links, give credits to contributors).
- Push release branch and create PR. Wait for tests to pass. Wait for the review process to complete.
- Delete all previous distributions in the
Create whl/tar.gz packages
python setup.py bdist_wheel sdist
Release to PyPI testing
python setup.py publishtest
Release to PyPI
python setup.py publish
In case of errors repeat steps 3-10.
- Create git tag in the form of
v2.1.0). Push the tag.
- Merge PR and delete PR branch (
- Change the version in
textX/__init__.pyto next minor version with
next-versionto keep it up-to-date.
- Update/release the docs
# mike deploy latest mike deploy latest -p # For major/minor version release # mike delete stable # this deletes alias stable # mike deploy 1.9 stable # and adds it to 1.9 minor version mike deploy 1.9 stable -p
For supporting previous versions only bugfix releases will be made. The process
is similar. The difference for support release would be that release process
would be based of the
support branch instead of the
master branch as is done
for regular releases. Thus, for support release, we would skip step 1, in step 5
we would create PR against the support branch, and we won't do steps 13-15.