Changes between Version 66 and Version 67 of ReleaseProcedure

Timestamp:

Nov 19, 2013, 2:29:48 AM (10 years ago)

Author:

Peter

Comment:

--

ReleaseProcedure

@@ -1 @@
-[[PageOutline(1-3,Contents,inline)]]
-
-= Publishing a release =
-
-These instructions cover how to release minor and patch releases in a
-project that uses trac/subversion for revision control and project
-management. How to release major releases is not covered yet since we
-have not done that (with the exception of the first release). Release
-numbering follows the normal convention of major.minor.patch and the
-APR (see http://apr.apache.org/versioning.html) guidelines for
-releases are used.
-
-The main development is performed in the trunk branch of the
-repository. A new release branch is created for each minor release
-from the trunk and patch releases are snapshots of the minor release
-branch. This implies that patch work is performed in the minor release
-branch, and changes made release branch is transferred to the trunk
-every time a new patch release is made. Remember, patch work should be
-limited to bug fixes and important fixes only leaving development of
-new features and designs to the trunk branch.
-
-Releases should only be performed by an appointed member of the team,
-the ''Release Manager'', and merges should be performed by a ''Merge
-Manager''. Of course, one team member can be both managers, thus
-becoming the ''Release'' and ''Merge Manager''.
-
-
-== Minor release procedure ==
-
-This section describes what to do when publishing a minor release.
-
-=== Creating a release branch ===
-
-Once people agree that a new release branch should be made, the
-''Release Manager'' creates it with the following procedure
-(substitute A.B with the version you are preparing, ''e.g.'' 0.3, or
-1.0):
-
- 1. Check that `YAT_LT_VERSION_INFO` is set correcly
-    otherwise update following line in `m4/version.m4`
-{{{
-m4_define([YAT_LT_VERSION_INFO], [c:r:a])
-}}}
- 1. Add a line in NEWS
-{{{
-See the end for copyrights and conditions.
-
-+yat A.B.x series from http://dev.thep.lu.se/yat/svn/branches/A.B-stable
-+
-Version A.B (released NOT YET)
-}}}
- commit the changes with `svn ci -m "Prepare A.B-stable branch"`[[br]][[br]]
- 1. Update copyright statements with command:
-{{{
-make copyright
-}}}
- Examine the updates and commit
- changes with `svn ci -m "updating copyright statements"`.  For this
- step [http://dev.thep.lu.se/svndigest svncopyright] is
- needed.[[br]][[br]]
- 1. Create a new minor branch using a one liner like
-{{{
-svn copy ^/trunk ^/branches/A.B-stable -m "New minor version A.B branch"
-}}}
- 1. Check out a WC from the newly created branch
-{{{
-svn co ^/branches/A.B-stable ../yat-A.B.x
-}}}
- 1. Copy the svndigest cache from trunk WC to branch WC
-{{{
-svndigest-copy-cache -v -r . -t ../yat-A.B.x
-}}}
-   which needs svndigest 0.8 or newer.[[br]][[br]]
- 1. Prepare the trunk for the next minor release [[br]][[br]]
-  i. Update version number in `m4/version.m4`. Locate and change the
-     below lines
-{{{
-MY_VERSION_early([A], [B+1], [0], [true])
-m4_define([YAT_LT_VERSION_INFO], [c+1:0:0])
-}}}
-  i. Add an entry in `NEWS`
-{{{
-version A.[B+1] (released NOT YET)
-}}}
-     The date is set when version A.[B+1] is released. [[br]][[br]]
-  i. Commit changes to the repository,
-     `svn ci -m "Bumping VERSION to A.[B+1]pre"` [[br]][[br]]
- 1. When someone with access to documentation site has time available, 
- they will upgrade to the new branch. This person is usually not the 
- release manager, so please send a reminder.
-
-=== Rolling a minor release ===
-
- 1. Make sure that all commits are performed into the minor branch, such
-    as bumping version number(s) (`version.m4`), update `NEWS`.
-    [[br]][[br]]
-  i. Update version number in `m4/version.m4`. Locate and change the
-     below line
-{{{
-MY_VERSION_early([A], [B], [0], [false])
-}}}
-  i. Update the interface version number in `m4/version.m4`. Locate and set the version in the
-     below line
-{{{
-m4_define([YAT_LT_VERSION_INFO], [c:r:a])
-}}}
-     appropriately. Refer to the interface version list in
-     `m4/version.m4` to figure out the settings of c, r, and a. c
-     should increase with 1 if the interface has changed. If the
-     interface is changed, r should be set to zero and a should be set
-     to reflect backward compatibility level of this version. If
-     interface was not changed just increase r with 1. See
-     `m4/version.m4` and the
-     [http://www.gnu.org/software/libtool/manual/html_node/Versioning.html#Versioning libtool manual] for details.[[br]][[br]]
-  i. Set the date for the new release in `NEWS`.
-{{{
-version A.B (released 26 June 2007)
-}}}
-    Make sure that the items in `NEWS` cover the new features of the
-    release. [[br]][[br]]
-  i. Commit changes to the repository, `svn ci -m "Preparing release A.B"`
-     [[br]][[br]]
- 1. Update copyright statements with command:
-{{{
-make copyright
-}}}
- Examine the updates and commit changes with `svn ci -m "updating copyright statements"`.
- For this step [http://dev.thep.lu.se/svndigest svndigest] is needed.[[br]][[br]]
- 1. Needless to say, make sure that the program is in a state to be
-    released; make sure that all the tests pass, test the distribution
-    package, and perform all other release tests you think is
-    appropriate:[[br]][[br]]
-    Run 
-{{{
-make release-tag-upload
-}}}
-    Fix potential problems.[[br]][[br]]
- 1. Update SubversionCheckout and WikiStart[[br]][[br]]
-  i. In section '''yat ''latest release'' ''' update link to
-     `[source:tags/A.B/NEWS NEWS]` and modify the svn commands to
-{{{
-svn checkout http://dev.thep.lu.se/yat/svn/tags/A.B yat-A.B
-}}}
-{{{
-svn switch http://dev.thep.lu.se/yat/svn/tags/A.B
-}}}
-  i. In section '''yat ''stable'' ''' update link to
-     `[milestone:A.B.1 A.B.1]` and modify the two svn commands to
-{{{
-svn checkout http://dev.thep.lu.se/yat/svn/branches/A.B-stable yat-A.Bdev
-}}}
-{{{
-svn switch http://dev.thep.lu.se/yat/svn/branches/A.B-stable
-}}}
-  i. In section '''yat ''devel'' ''' update link to `[milestone:A.B+1 A.B+1]`.[[br]][[br]]
-  i. On WikiStart update links `[source:tags/A.B/NEWS NEWS]` and 
-     `[source:branches/A.B-stable/README README]`.[[br]][[br]] 
- 1. Close the [http://dev.thep.lu.se/yat/roadmap milestone] associated
-    with the release and replace `head` with appropriate revision. Add
-    a new milestone as needed (with log link).[[br]][[br]]
- 1. Update the version list in Trac using the
-    [http://dev.thep.lu.se/yat/admin/ticket/versions trac-admin tool].
- 1. Use `announcement.txt` as template and send email to libyat-users@lists.sourceforge.net
- 1. Merge the minor release into the trunk. To avoid confusion and
-    minimize the risk of loosing fixes, this step is only performed by
-    the ''Merge Master''. [[br]][[br]]
-  i. Go to a pristine trunk WC
-{{{
-cd /path/to/yat-trunk/
-svn update
-svn status -q
-}}}
-  i. Merge changes into trunk.
-{{{
-svn merge ^/branches/A.B-stable
-}}}
-  i. Resolve all conflicts. Run tests and perform all other
-     appropriate tests to make sure that the merge does not create
-     havoc. Typically changes in `m4/version.m4` are problematic
-     so check this file extra carefully.[[br]][[br]]
-  i. Commit changes to the trunk branch.
-{{{
-svn commit -m "Merged release A.B to the trunk."
-}}}
- 1. Prepare the minor branch for the first patch release [[br]][[br]]
-  i. Update version number in `m4/version.m4`. Locate and change the
-     below line
-{{{
-MY_VERSION_early([A], [B], [1], [true])
-}}}
-  i. Add an entry in `NEWS`
-{{{
-version A.B.1 (released NOT YET)
-}}}
-     The date is set when version A.B.1 is released. [[br]][[br]]
-  i. Commit changes to the repository,
-     `svn ci -m "Bumping VERSION to A.B.1"` [[br]][[br]]
-
-
-== Patch release procedure ==
-
-This section describes what to do when publishing a patch release A.B.C.
-
- 1. Make sure that all commits are performed into to the branch, such
-    as bumping version number(s) (`configure.ac`), update `NEWS`. [[br]][[br]]
-  i. Update the release version number in `m4/version.m4`. Locate and change the
-     below line
-{{{
-MY_VERSION_early([A], [B], [C], [false])
-}}}
-     Confirm `YAT_LT_VERSION_INFO` and add an entry in list of versions.[[br]][[br]]
-  i. Set the date for the new release in `NEWS`
-{{{
-version A.B.C (released 27 June 2007)
-}}}
-    Make sure that the items in `NEWS` cover all important bug fixes of the
-    release. [[br]][[br]]
-  i. Commit changes to the repository, `svn ci -m "Preparing release A.B.C"`
-     [[br]][[br]]
- 1. Update copyright statements with command:
-{{{
-make copyright
-}}}
- Examine the updates and commit changes with `svn ci -m "updating copyright statements"`.
- For this step [http://dev.thep.lu.se/svndigest svncopyright] is obviously needed.[[br]][[br]]
- 1. Needless to say, make sure that the program is in a state to be
-    released; make sure that all the tests pass, test the distribution
-    package, and perform all other release tests you think is
-    appropriate:[[br]][[br]]
-    Run
-{{{
-make release-tag-upload
-}}}
-    Fix potential problems.[[br]][[br]]
- 1. Update SubversionCheckout and [wiki:WikiStart WikiStart][[br]][[br]]
-  i. In section '''yat ''latest release'' ''' update link to
-     `[source:tags/A.B.C/NEWS NEWS]` and modify the svn commands to
-{{{
-svn checkout http://dev.thep.lu.se/yat/svn/tags/A.B.C yat-A.B.C
-}}}
-{{{
-svn switch http://dev.thep.lu.se/yat/svn/tags/A.B.C
-}}}
-  i. In section '''yat ''stable'' ''' update link to
-     `[milestone:A.B.[C+1] A.B.[C+1]]`.[[br]][[br]]
-  i. On WikiStart update reference to explicit latest version number, and `[source:tags/A.B/NEWS NEWS]`.[[br]][[br]] 
- 1. Close the milestone associated with the release, replace `head`
-    with appropriate revision in log link, set diff to
-    '`diff:tags/A.B.[C-1]//tags/A.B.C/`'. Create a log link,
-    '`log:branches/A.B-stable@TAG-REVISION:head`', and diff,
-    '`diff:tags/A.B.C//branches/A.B-stable/`', in milestone associated
-    with next patch release.[[br]][[br]]
- 1. Update the version list in Trac using the
-    [http://dev.thep.lu.se/yat/admin/ticket/versions trac-admin tool].
-    Remember to set the date.[[br]][[br]]
- 1. Use `announcement.txt` as template and send email to libyat-users@lists.sourceforge.net
- 1. Merge the patch release into the trunk. To avoid confusion and
-    minimize the risk of loosing fixes, this step is only performed by
-    the ''Merge Master''. [[br]][[br]]
-  i. cd to a pristine trunk WC
-{{{
-cd /path/to/yat-trunk/
-svn update
-svn status -q
-}}}
-  i. Merge changes into trunk. In this example the diffence between a
-     minor release tag and the first patch release tag is merged into
-     the trunk WC
-{{{
-svn merge ^/branches/A.B-stable
-}}}
-  i. Resolve all conflicts. Run tests and perform all other
-     appropriate tests to make sure that the merge does not create
-     havoc. Typically changes in `m4/version.m4` are problematic
-     so check this file extra carefully.[[br]][[br]]
-  i. Commit changes to the trunk branch.
-{{{
-svn commit -m "Merged patch release A.B.1 to the trunk."
-}}}
- 1. Prepare the minor branch for the next patch release [[br]][[br]]
-  i. Update version number in `m4/version.m4`. Locate and change the
-     below line
-{{{
-MY_VERSION_early([A], [B], [C+1], [true])
-}}}
-  i. Update the interface version number in `m4/version.m4`. Locate and change the
-     below line
-{{{
-m4_define([YAT_LT_VERSION_INFO], [c:r+1:a])
-}}}
-     i.e., only raise the revision number since the interface will not
-     change. See the
-     [http://www.gnu.org/software/libtool/manual/html_node/Versioning.html#Versioning libtool manual] for details.[[br]][[br]]
-  i. Add an entry in `NEWS`
-{{{
-version A.B.[C+1] (released DATE)
-}}}
-     The date is set when version A.B.[C+1] is released. [[br]][[br]]
-  i. Commit changes to the repository,
-     `svn ci -m "Bumping VERSION to A.B.[C+1]"` [[br]][[br]]
+This document has moved to [source:branches/0.11-stable/README.developer]