User Tools

Site Tools


difx:release

This is an old revision of the document!


The DiFX Release Process

The guidelines here are not strict and may change version to version, but document the typical process used in releasing a new DiFX version.

  1. Upon nearing feature completeness or some other indicator that a release is due, somebody should email the DiFX Developers email list, encouraging a quick wrap-up of current developments for the upcoming release.
  2. A countdown page like this is usually created at this time to track remaining work to be done and start building release notes.
  3. A second email indicating feature completeness and transition to bug fix only state is sent out when the countdown list contains only testing and documentation items.
  4. Upon general agreement that the tree is ready for tagging a final email is sent suggesting that.
  5. The release tagging operation involves the following steps
    1. Make the subversion tree for the release, including the version directory (e.g., DiFX-2.0.1) and its subdirectories (libraries, applications, …)
    2. Update ChangeLog entries to include the new DiFX version and possibly a date.
    3. Commit the ChangeLog
    4. Make sure the configure.ac for each package requires proper versions of libraries (usually statements starting with PKG_CHECK_MODULES)
    5. If you copy the above line, be sure to change the quotes to normal quotes or else the svn cp command will fail with a misleading error message!
    6. Go back to the trunk version of each package and bump the version (usually in configure.ac) and note this in the ChangeLog.
    7. Recommit the trunk version.
  6. Announce to the DiFX Users mailing list that the new version is ready, including a copy of release notes.
difx/release.1308598341.txt.gz · Last modified: 2011/06/21 05:32 by adamdeller