Versioning and deprecating¶
Versioning process¶
udata follows Python PEP 440 on versioning to version its published releases.
Branches management¶
There is a main branch on the udata git repository, master
and some temporary feature branches.
The 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
Every version has a git tag vX.Y.Z
.
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.
The contents of each version (expected or real) is tracked trough issues, pull requests and sometimes discussions.
Releasing¶
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
master
branch - have
bumpr
installed
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
- run
bumpr -d -v
to preview the actions performed and the changes - run
bumpr
to 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
- commit
- set a git tag with the version (
vX.Y.Z
) - perform next iteration replacements (increased dev version, URLs)
- prepare the changelog for the next iteration
- commit
- 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
- celebrate!
Feature branches¶
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 X.Y.Z.devBBB+my-feature
where BBB
is the build number.
Deprecation policy¶
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).