Release Process

So you want to release a new version, great!

First, make sure all the desired pull requests have been merged.

Next, pull the latest translations.

Finally, here are the steps to follow.

Get a clean environment

Create a new virtual environment (pew makes this trivial), then get the code:

$ pew mktmpenv -p python3
$ git clone git@framagit.org:ideascube/ideascube.git
$ cd ideascube
$ git checkout master

Now install all the dependencies:

$ make develop

Sanity check

Run the tests:

$ py.test

And run the migrations:

$ make migrate

Let's make sure there are no migration conflicts with the previous release:

$ make test-data-migration

If the above succeeded, you should update the test data file so it can be used by the CI after this release:

$ python manage.py dumpdata --database=default \
      --natural-foreign -e sessions -e contenttypes -e auth.Permission \
      --format=json --indent=4 -o test-data/data.json
$ git add test-data/data.json
$ git commit -m "Update the migration test data"

Release

First, decide what the new version will be. Is it a new major, minor or patch release?

At the moment, since we are still in the pre-1.0 days, we usually follow this convention:

  • if the release introduces new features, bump the minor version;
  • if the release only fixes bugs, adds config files, then bump the patch version.

Write the debian/changelog entry for the new version. Review all the commits in master since the last release to make sure you don't forget anything.

Bump the version in ideascube/__init__.py.

Commit, using the new version as the commit message:

$ git commit -a -m "x.x.x"

Create a new tag named after the new version:

$ git tag x.x.x

Push the release:

$ git push origin master x.x.x

Make yourself a drink while you wait for Buildbot to finish building the Debian packages. Follow its progress at http://buildbot.ideascube.org/waterfall