Versioning and deprecating¶
udata follows Python PEP 440 on versioning to version its published releases.
There is a main branch on the udata git repository,
and some maintenance branches
master is the stable development branch on which:
- bug fixes should occur (unless the bug is only present on a maintenance branch)
- security upgrades are done (unless only necessary on a maintenance branch)
- the incoming new features (and their bug fixes)
- the refactoring
- the dependencies upgrades
- translations are done
- releases are done
vX.Y maintenance branches host:
- the bug fixes and security upgrades associated to these versions only
- the backported bug fixes and security upgrades
Every minor version has a maintenance branch
vX.Y and every version has a git tag
Otherwise the version is
X.Y.Z.dev (1.1.7.dev) so you can easily see when you are not using a stable release.
udata uses Bump’R as its release process.
To create a release, you need to:
- have administrator permission on the udata repository (to allow direct push)
- have a working development environment up to date with the
The step to make a release are:
- fetch latest changes from upstream repository
- ensure translations are up to date
- ensure the CircleCI build is successful on master branch
- ensure your working copy is clean
bumpr -d -vto preview the actions performed and the changes
bumprto perform the release. This will:
- clean up remaining build artifacts
- execute tests
- perform a full packaging (to ensure it is working)
- perform replacements (bumped version, URLs)
- set the changelog version and date
- set a git tag with the version (
- perform next iteration replacements (increased dev version, URLs)
- prepare the changelog for the next iteration
- push (commits and tags)
- check on github that everything has been pushed
- wait for CircleCI tagged build to succeed
- check on PyPI that the new release is present
We need to branch the master each time a minor version development cycle starts:
- create a branch for the current minor version. E.g.: if the current master version is
1.1.8.dev, create a
git checkout -b v1.1
- publish the branch to the official repository:
git push -u origin vX.Y
- get the
git checkout master
- increment the version in
Fixing an old version¶
Switch on the maintenance branch you need:
git checkout vX.Y
Create a new branch from the maintenance one and perform a pull request from it:
git checkout -b my-fix # fix fix fix git commit git push -u myrepository my-fix
Sometimes a new feature or an EPIC requires more than one pull request and a lot of testing.
For these cases, it’s not desirable to use the
master branch to test until it’s stable because we want to keep the
master branch as stable as possible.
To handle these cases we are using feature branches, named like
feature/my-feature. These branches will build on CircleCI and produce a local version package.
The local identifier will be the feature branch name so the version number will be
BBB is the build number.
When it’s possible deprecations are published 2 minor versions before being really dropped. It’s up to the developers and system administrators to read the changelog before upgrading (deprecations and breaking changes are published).