Skip to content

Release Management

Tobias Schlauch edited this page Mar 21, 2016 · 3 revisions

This page explains the basics of the DataFinder release management.

Release Number Format

  • The release number format is:
major.minor.bugfix

Examples: 2.0.0, 2.1.0, 2.2.1

  • Increase the major part if you made "big" changes or changes that cause non-trivial updates, e.g. completely new GUI, changes of the storage format, incompatible script API.
  • Increase the minor part for regular feature releases.
  • Increase the bugfix part for releases which resolve a number of bugs.

Release Planning

At least all major and minor releases should be planned. For release planning the GitHub issue tracker is used.

If you want to add a new release, you should perform the following steps:

  • Add a new milestone and specify at least a name, the expected release date, and a short description.
  • Use the following milestone name template: DataFinder RELEASE_NUMBER

Release Creation

  • Preparation:

  • All issues of the specific milestone are fixed / implemented.

  • Documentation is updated:

  • All tests are successfully performed using the latest SNAPSHOT release:

  • Perform tests for all supported operating systems (see operating systems for which a build job exists).

  • Use the test script for every meta data / data store.

  • Manually check the basic functionalities following this Testmatrix.pdf.

  • Release creation:

  • Connect to the Continuous Integration system (DLR-internal only). Perform a release build for every supported operating system.

  • Make sure your are logged in and have sufficient privileges.

  • Create a release for every Nightly Build using the release button. * Release options:

    • RELEASE_VERSION: Specify the release number, e.g. 2.2.0
    • GENERATE_RELEASE_VERSIONS: For Windows XP you can attach the generated NSIS installers a configuration URI. Just add a new name URI pair for an additional release. Create Release View in Jenkins
  • Tag the master:

git tag -a <TAG_NAME> <REVISION>
For **<TAG_NAME>** use the release number (e.g., 2.2.0). For **<REVISION>** use the Git revision on which the release build is based (e.g., 15027957951b64cf874c3557a0f3547bd83b3ff6). 
  • Post work:
  • Set the version property in the file setup.cfg to the next release number.
  • Release the corresponding milestone on GitHub.
  • Attach the default release files to the milestone and rename them as required:
    • Clients: DataFinder-<X.Y.Z>-RELEASE-<REVISION>_User+Admin.<[exe|.tar.gz]>
    • Source: DataFinder-<X.Y.Z>-RELEASE-<REVISION>.<[zip|.tar.gz]>
    • Scripting API: DataFinder-Scripting-API-<X.Y.Z>-RELEASE-<REVISION>.<[zip|.tar.gz]>