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 maintenance branches vX.Y
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
The 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 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 milestones.
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!
Branching¶
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 av1.1
branch withgit checkout -b v1.1
- publish the branch to the official repository:
git push -u origin vX.Y
- get the
master
branch back:git checkout master
- increment the version in
udata/__init__.py
: E.g.1.1.8.dev
become1.2.0.dev
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
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).