Skip to end of metadata
Go to start of metadata

The releases of our software are handled according to this process.

On this Page

Release Management Policy

The policy describing version numbering and support can now be found on this page: Release management policy

Release check list

This is a description of what should be done before a release.

Step 1. Decide to prepare a release

Team decides they are ready to prepare a release based on review of feature development and open bugs.

Step 2. Update documentation

All developers update the content of the documentation pages.

Step 3. Check the database migration tool is up to date

If any changes to the schema have been made the scripts may need updating

Step 5. Agree the release type and support period

Is this a LTS or standard release? Update the Release policy page with a new minor/major release if needed.

Step 4. Complete all testing

All developers ensure that their code passes all existing jenkins tests (and any new added for the feature). Does it compile on all known platforms? Are there no warnings? Does the test suite verify? 

Step 5. Code Reviews

Team performs reviews of the changes made between the latest and upcoming release. This might result in new changes. If so, iterate from step 3 until 'done'.

Step 6. Run code integrity tools

Someone (TBA) run Coverity on the code base. This might result in new changes. If so, iterate from step 3 until 'done'.

Step 7. Agree to release

Team decision that code is ready to release. 

Release process

This is a description on how to do a release. To be done by the 'Project manager' unless otherwise stated.

Step 1: Update the documentation

  • Verify if the documentation it is up to date, correct and relevant. This includes the files README and KNOWN_ISSUES.
  • Verify the NEWS file and check if all important feature additions, modifications and bugfixes are listed there. Check if all planned changes are present. 
  • For a major release only update the wiki space by creating a new version: Update the documentation, following the Document management process
    • Grab the new versions of the documentation in PDF and HTML format and add to the source in a 'docs' directory. 

Step 2: Testing

  • Double check the revision to be released passes all Jenkins tests. Run the daily/weekly tests manually if needed.

 

All stable releases should have a release candidate made available to the maintainers for at least 1 week before the full release is performed.

Note that no code freeze is put in place on the branch following the first release candidate so for the actual release (and any release candidates after the first one) the release should be based on the rc1 tag NOT the branch.
Any fixes in the branch that are required in a subsequent release candidate must be manually merged with the rc1 code base.  

 

Step 3: Generate the release

  • Create a tarball using the Release Engineering Process (Release engineer)
  • Verify the tarball: Is it complete? Does it contain no unnecessary things (e.g. build files)? Does it work (build/install)? (Release engineer)

For a Release candidate

  • Update the versions in JIRA
    • Create a rc version for next release (if it doesn't already exist) in OpenDNSSEC project
    • Mark this rc version as 'released' in the OpenDNSSEC project - JIRA should prompt you to move all open issues to the next release. Choose yes and do this.
    • Add the equivalent of the rc version to the SUPPORT project and mark it as released so that issues can be raised against it.
  • Send an announcement to the maintainers list and try to include the planned date of the full release. Give maintainers at least a week for testing creating packages/updating ports. (PM)
    • If issues are found, a new release candidate has to be made and sent out again. 

For a Production release

  • Add the new tarball to the Wordpress Download page.
  • Update the versions in JIRA again
    • Change the name of the rc versions in both the OpenDNSSEC and SUPPORT projects to be a production version and update the release date.
    • Update any 'standard' JIRA queries to include the new version (the team meeting agenda also contains links to the current release)

Step 4: Announcements 

For a Release candidate

  • Send an announcement to the maintainers list and try to include the planned date of the full release. Give maintainers at least a week for testing creating packages/updating ports. (PM)
    • If issues are found, a new release candidate has to be made and sent out again. 

For a Production release

  • Announce the new version:
    1. Add a new post on the Wordpress site 
    2. Send an e-mail to the announce mailing-list 
    3. Twitter message 
    4. Add a message to the Facebook page
    5. New version on Freshmeat.net 
  • No labels