So you want to release a new version, great!
-
make sure you are on master
-
make sure you are up to date with upstream
-
make sure all the wanted PR are merged (https://github.com/ideascube/ideascube/pulls)
-
run the tests by running the command
py.test -
make sure there is no migration conflicts: checkout latest released version tag, reset the database, checkout master HEAD again, run the migrations
-
decide the new version: major, minor, patch? Usually, what I follow (as we are in pre-1.0) is: new feature means new minor; fixes, new config files, etc. are new patch only.
-
create a new version in the
debian/changelogfile (I do it by hand, copy-pasting the previous one, and updating everything) -
browse https://github.com/ideascube/ideascube/commits/master to make sure your don't forget anything in the changelog entries
-
bump the version in
ideascube/__init__.py -
commit, using the new version as message:
git commit -a -m "x.x.x" -
create a new tag:
git tag x.x.x -
push the new commit:
git push -
push the new tag:
git push --tag -
wait for buildbot to finish in http://buildbot.ideascube.org/waterfall
-
fruit champagne!
-
Bonus: one may update the translations before releasing, but that's a tricky one containing edge cases (what if the new translations fail to build?), so let's see that in the next episode!
gotta wikify em all!