User Tools

Site Tools


difx:release

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
Next revisionBoth sides next revision
difx:release [2014/11/05 02:38] walterbriskendifx:release [2020/09/12 06:53] geoffcrew
Line 1: Line 1:
-=== The DiFX Release Process ===+ 
 +==== 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. The guidelines here are not strict and may change version to version, but document the typical process used in releasing a new DiFX version.
 +
 +=== General principles ===
 +
 +  * We aim for a major release every ~12 months
 +  * In between major releases, minor releases are made on an as-needed basis.  Minor releases should really only be for bugfixes or very minor feature additions.
 +
 +=== How to do a minor release ===
 +
 +  * Test your change in trunk
 +  * Test your change in master-tags/DiFX-2.X/
 +  * Update the ChangeLog(s) and update package version requirements if needed
 +  * Update the wiki [[changelog]]
 +  * Email difx-developers and announce the intention to make a new minor release:
 +    * Request testing of the updated DiFX-2.X
 +    * Indicate timeline and community requirements (with respect to schedule)
 +  * After testing is complete:
 +    * svn copy master-tags/DiFX-2.X/ master-tags/DiFX-2.X.Y/
 +    * update the setup.bash and setup.csh with the new DIFX_VERSION identifier
 +    * Compile test the new tag
 +    * Update [[news]] and [[installation]] with the new version number
 +    * Update [[difx2.0tonow]] with major changes
 +    * email difx-users and announce the new release
 +
 +=== How to do a major release ===
  
   - 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.   - 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.
-  - A countdown page [[d201countdown|like this]] is usually created at this time to track remaining work to be done and start building release notes.+  - A countdown page [[d201countdown|like this]] may be created at this time to track remaining work to be done and start building release notes.
   - 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.   - 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.
   - Upon general agreement that the tree is ready for tagging a final email is sent suggesting that.   - Upon general agreement that the tree is ready for tagging a final email is sent suggesting that.
   - The release tagging operation involves the following steps   - The release tagging operation involves the following steps
-    - Make the subversion tree for the release, including the version directory (e.g., DiFX-2.0.1) and its subdirectories (libraries, applications, ...)+    - Make the subversion tree for the release, including the version directory (e.g., DiFX-2.6) and its subdirectories (libraries, applications, ...)
     - Update ChangeLog entries to include the new DiFX version and possibly a date.     - Update ChangeLog entries to include the new DiFX version and possibly a date.
     - Commit the ChangeLog     - Commit the ChangeLog
     - Make sure the configure.ac for each package requires proper versions of libraries (usually statements starting with PKG_CHECK_MODULES)     - Make sure the configure.ac for each package requires proper versions of libraries (usually statements starting with PKG_CHECK_MODULES)
-    - Do a subversion copy, e.g.,  svn cp https://svn.atnf.csiro.au/difx/libraries/difxio/trunk https://svn.atnf.csiro.au/difx/master_tags/DiFX-2.0.1/libraries/difxio -m "Tag for version 2.0.1"+    - Do a subversion copy, e.g.,  svn cp https://svn.atnf.csiro.au/difx/libraries/difxio/trunk https://svn.atnf.csiro.au/difx/master_tags/DiFX-2.6/libraries/difxio -m "Tag for version 2.6"
     - 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!     - 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!
     - Go back to the trunk version of each package and bump the version (usually in configure.ac) and note this in the ChangeLog.     - Go back to the trunk version of each package and bump the version (usually in configure.ac) and note this in the ChangeLog.
     - Recommit the trunk version.     - Recommit the trunk version.
-  - Announce to the DiFX Users mailing list that the new version is ready, including a copy of release notes. +  - Run through the minor release procedure to create DiFX-2.X.1/ from your new DiFX-2.X/ tag.
-  Edit the [[news]] page of the wiki with the release date+
  
 A script, current for DiFX-2.4, is below.  For future versions change ''NEW_VERSION'' and check for package completeness. A script, current for DiFX-2.4, is below.  For future versions change ''NEW_VERSION'' and check for package completeness.
difx/release.txt · Last modified: 2023/02/22 20:53 by helgerottmann