User Tools

Site Tools


Organization of the release process

Versioning & Release numbers

  • Scheme: major.minor.bugfix
  • Minor version should be changed when features like new views are introduced
  • Bugfix version should be changed whenever bugs are fixed (or minor small features were added)
  • The compatibility with existing sessions or databases should not be broken with Bugfix releases!

Organization of releases

We use the bug tracker to organize the release process using the following milestones:

  • any future version: Used for all new bugs and feature requests
  • next release: The bug should be fixed in the next release

For each new version, there should be a bug report with the title Scaffold Hunter version x.y.z release request. This should give all developers the chance to discuss serious bugs that should be fixed for the next release. In the course of the discussion it can be decided if the next version should be a feature or bugfix release. When a new version has been released, the milestone “next release” is renamed to the concrete new version.

Creating a new release

Typically a new release (major and minor) is based on master.

Update repository files

Update changelog.txt

Add important changes. These can be obtained from tickets in the bug/feature tracker marked as “next release” and the Git history. Add a warning if the release is incompatible with old databases or old sessions, if necessary.


The manual shows the version number without bugfix revision (e.g., “Version 2.3”) at the title page. The file doc/manual.tex must be updated whenever major or minor version number is changed.

Commit changes

When the changes described above are done, they should be committed to the local branch with the commit message “Preparing release 2.3.1”. It is important to not push the changes to the remote repository. In case of build or test errors (next section) this allows to amend the commit and redo the commit without having the false commit in the public commit history.

Building and testing the release

  1. Update the working copy and make sure it is clean, i.e., it does not contain any changes.
  2. Run JUnit tests, e.g., using Eclipse
  3. Create a tag for the new release with the following command:
    git tag -a "release-2.3.1" -m "tagging release: 2.3.1"
  4. Build the release with the command “ant release”
  5. Check the content of the subfolder “release”, it should contain the following files (typically the size of the archives should not differ significantly from the previous release; if it does, it is likely that they contain files that should not be included!):
    • changelog.txt
    • readme.txt
    • scaffoldhunter-2.3.1.ebuild
    • scaffold-hunter-src-2.3.1.tar.gz
  6. Test the release, e.g.,
    • Unpack the zip file to a different folder
    • Start and test the software
    • Start and test the demo mode. Verify that all views are opened correctly and do not contain any visual glitches.
    • Verify that the “About” dialog contains the correct version number and year
    • Check that the manual.pdf looks fine, e.g., references

Update remote repository

The following examples assume, that the local branch of our master branch at SourceForge is also called “master” and the SourceForge remote is called “origin”.

Push local changes

git push origin master
git push origin release-2.3.1

Publish the release

  1. Create a new folder “2.3.1” under “Files” (Scaffold Hunter Sourceforge homepage)
  2. Upload the above mentioned files found in the release folder
  3. Click on the button “View Details” of the file “” and make it the default download for all operating systems. The download button should be labeled with “Scaffold Hunter v2.3.1”
  4. Write a news message and post it on the homepage (section News) and send it to the mailing list

Update bug and feature tracker

  • Rename the milestone “next release” to the new version number, e.g., “2.3.1”
  • Create a new milestone “next release”
release_process.txt · Last modified: 2016/09/09 14:19 by till