Versionning and deprecations¶
Versionning process¶
UData uses semantic versionning to publish its published releases.
Branches management¶
There is two main branches on the UData git repository: master
and dev
The master
is the stable development branch on which:
- bug fixes should occurs (unless is only present on
dev
branch) - bugfix or security upgrades (only) are done
- translations are done
- releases are done
The dev
branch hosts:
- the incoming new features (and their bug fixes)
- the factoring
- the dependencies upgrades
- the bug fixes associated to these
There is always at least one minor version between the dev
and the master branch
(ie. 1.0.2.dev
on master
and 1.1.0.dev
on dev
).
Every version has a git tag X.Y.Z
and then when bug fixes need to be applied
without publishing new changes, there will be a version branch X.Y
The content of each version (expected or real) is tracked trough issues, pull requests and milestones.
Merging¶
Regular imports of changes from master
branch are done into the dev
branch
in the form of pull requests (ideally from a branch named merge-master-YYYY-MM-DD
).
Merge from dev
to master
branch are done when the dev branch is considered stable
and should not receive new features.
Releasing¶
UData uses Bump’R to perform its release process.
To be perform a release, you’ll 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 perform a release are:
- fetch latest changes from upstream repository
- ensure translations are up to date
- ensure 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 its working)
- perform replacements (bumped version, URLs)
- set the changelog version and date
- commit
- set a git tag with the version (
X.Y.Z
) - perform next iterationreplacements (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
Fixing an old version¶
If this is first bug fix, create a branch associated with the minor version
(ie. X.Y
when the tag is X.Y.0
) and and publish it:
git checkout -b X.Y X.Y.0
git push -u origin X.Y
If the branch already exists, just switch on it:
git checkout X.Y
Perform a pull request from this branch:
git checkout -b my-old-fix
# fix fix fix
git commit
git push -u myrepository my-old-fix
Deprecation policy¶
When it’s possible deprecation are signaled 2 minor versions before being really dropped. It’s up to the developpers and system administrators to read the changelog before upgrading (deprecations and breaking changes are signaled).