Changes between Version 66 and Version 67 of ReleaseProcedure


Ignore:
Timestamp:
Nov 19, 2013, 2:29:48 AM (7 years ago)
Author:
Peter
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ReleaseProcedure

    v66 v67  
    1 [[PageOutline(1-3,Contents,inline)]]
    2 
    3 = Publishing a release =
    4 
    5 These instructions cover how to release minor and patch releases in a
    6 project that uses trac/subversion for revision control and project
    7 management. How to release major releases is not covered yet since we
    8 have not done that (with the exception of the first release). Release
    9 numbering follows the normal convention of major.minor.patch and the
    10 APR (see http://apr.apache.org/versioning.html) guidelines for
    11 releases are used.
    12 
    13 The main development is performed in the trunk branch of the
    14 repository. A new release branch is created for each minor release
    15 from the trunk and patch releases are snapshots of the minor release
    16 branch. This implies that patch work is performed in the minor release
    17 branch, and changes made release branch is transferred to the trunk
    18 every time a new patch release is made. Remember, patch work should be
    19 limited to bug fixes and important fixes only leaving development of
    20 new features and designs to the trunk branch.
    21 
    22 Releases should only be performed by an appointed member of the team,
    23 the ''Release Manager'', and merges should be performed by a ''Merge
    24 Manager''. Of course, one team member can be both managers, thus
    25 becoming the ''Release'' and ''Merge Manager''.
    26 
    27 
    28 == Minor release procedure ==
    29 
    30 This section describes what to do when publishing a minor release.
    31 
    32 === Creating a release branch ===
    33 
    34 Once people agree that a new release branch should be made, the
    35 ''Release Manager'' creates it with the following procedure
    36 (substitute A.B with the version you are preparing, ''e.g.'' 0.3, or
    37 1.0):
    38 
    39  1. Check that `YAT_LT_VERSION_INFO` is set correcly
    40     otherwise update following line in `m4/version.m4`
    41 {{{
    42 m4_define([YAT_LT_VERSION_INFO], [c:r:a])
    43 }}}
    44  1. Add a line in NEWS
    45 {{{
    46 See the end for copyrights and conditions.
    47 
    48 +yat A.B.x series from http://dev.thep.lu.se/yat/svn/branches/A.B-stable
    49 +
    50 Version A.B (released NOT YET)
    51 }}}
    52  commit the changes with `svn ci -m "Prepare A.B-stable branch"`[[br]][[br]]
    53  1. Update copyright statements with command:
    54 {{{
    55 make copyright
    56 }}}
    57  Examine the updates and commit
    58  changes with `svn ci -m "updating copyright statements"`.  For this
    59  step [http://dev.thep.lu.se/svndigest svncopyright] is
    60  needed.[[br]][[br]]
    61  1. Create a new minor branch using a one liner like
    62 {{{
    63 svn copy ^/trunk ^/branches/A.B-stable -m "New minor version A.B branch"
    64 }}}
    65  1. Check out a WC from the newly created branch
    66 {{{
    67 svn co ^/branches/A.B-stable ../yat-A.B.x
    68 }}}
    69  1. Copy the svndigest cache from trunk WC to branch WC
    70 {{{
    71 svndigest-copy-cache -v -r . -t ../yat-A.B.x
    72 }}}
    73    which needs svndigest 0.8 or newer.[[br]][[br]]
    74  1. Prepare the trunk for the next minor release [[br]][[br]]
    75   i. Update version number in `m4/version.m4`. Locate and change the
    76      below lines
    77 {{{
    78 MY_VERSION_early([A], [B+1], [0], [true])
    79 m4_define([YAT_LT_VERSION_INFO], [c+1:0:0])
    80 }}}
    81   i. Add an entry in `NEWS`
    82 {{{
    83 version A.[B+1] (released NOT YET)
    84 }}}
    85      The date is set when version A.[B+1] is released. [[br]][[br]]
    86   i. Commit changes to the repository,
    87      `svn ci -m "Bumping VERSION to A.[B+1]pre"` [[br]][[br]]
    88  1. When someone with access to documentation site has time available,
    89  they will upgrade to the new branch. This person is usually not the
    90  release manager, so please send a reminder.
    91 
    92 === Rolling a minor release ===
    93 
    94  1. Make sure that all commits are performed into the minor branch, such
    95     as bumping version number(s) (`version.m4`), update `NEWS`.
    96     [[br]][[br]]
    97   i. Update version number in `m4/version.m4`. Locate and change the
    98      below line
    99 {{{
    100 MY_VERSION_early([A], [B], [0], [false])
    101 }}}
    102   i. Update the interface version number in `m4/version.m4`. Locate and set the version in the
    103      below line
    104 {{{
    105 m4_define([YAT_LT_VERSION_INFO], [c:r:a])
    106 }}}
    107      appropriately. Refer to the interface version list in
    108      `m4/version.m4` to figure out the settings of c, r, and a. c
    109      should increase with 1 if the interface has changed. If the
    110      interface is changed, r should be set to zero and a should be set
    111      to reflect backward compatibility level of this version. If
    112      interface was not changed just increase r with 1. See
    113      `m4/version.m4` and the
    114      [http://www.gnu.org/software/libtool/manual/html_node/Versioning.html#Versioning libtool manual] for details.[[br]][[br]]
    115   i. Set the date for the new release in `NEWS`.
    116 {{{
    117 version A.B (released 26 June 2007)
    118 }}}
    119     Make sure that the items in `NEWS` cover the new features of the
    120     release. [[br]][[br]]
    121   i. Commit changes to the repository, `svn ci -m "Preparing release A.B"`
    122      [[br]][[br]]
    123  1. Update copyright statements with command:
    124 {{{
    125 make copyright
    126 }}}
    127  Examine the updates and commit changes with `svn ci -m "updating copyright statements"`.
    128  For this step [http://dev.thep.lu.se/svndigest svndigest] is needed.[[br]][[br]]
    129  1. Needless to say, make sure that the program is in a state to be
    130     released; make sure that all the tests pass, test the distribution
    131     package, and perform all other release tests you think is
    132     appropriate:[[br]][[br]]
    133     Run
    134 {{{
    135 make release-tag-upload
    136 }}}
    137     Fix potential problems.[[br]][[br]]
    138  1. Update SubversionCheckout and WikiStart[[br]][[br]]
    139   i. In section '''yat ''latest release'' ''' update link to
    140      `[source:tags/A.B/NEWS NEWS]` and modify the svn commands to
    141 {{{
    142 svn checkout http://dev.thep.lu.se/yat/svn/tags/A.B yat-A.B
    143 }}}
    144 {{{
    145 svn switch http://dev.thep.lu.se/yat/svn/tags/A.B
    146 }}}
    147   i. In section '''yat ''stable'' ''' update link to
    148      `[milestone:A.B.1 A.B.1]` and modify the two svn commands to
    149 {{{
    150 svn checkout http://dev.thep.lu.se/yat/svn/branches/A.B-stable yat-A.Bdev
    151 }}}
    152 {{{
    153 svn switch http://dev.thep.lu.se/yat/svn/branches/A.B-stable
    154 }}}
    155   i. In section '''yat ''devel'' ''' update link to `[milestone:A.B+1 A.B+1]`.[[br]][[br]]
    156   i. On WikiStart update links `[source:tags/A.B/NEWS NEWS]` and
    157      `[source:branches/A.B-stable/README README]`.[[br]][[br]]
    158  1. Close the [http://dev.thep.lu.se/yat/roadmap milestone] associated
    159     with the release and replace `head` with appropriate revision. Add
    160     a new milestone as needed (with log link).[[br]][[br]]
    161  1. Update the version list in Trac using the
    162     [http://dev.thep.lu.se/yat/admin/ticket/versions trac-admin tool].
    163  1. Use `announcement.txt` as template and send email to libyat-users@lists.sourceforge.net
    164  1. Merge the minor release into the trunk. To avoid confusion and
    165     minimize the risk of loosing fixes, this step is only performed by
    166     the ''Merge Master''. [[br]][[br]]
    167   i. Go to a pristine trunk WC
    168 {{{
    169 cd /path/to/yat-trunk/
    170 svn update
    171 svn status -q
    172 }}}
    173   i. Merge changes into trunk.
    174 {{{
    175 svn merge ^/branches/A.B-stable
    176 }}}
    177   i. Resolve all conflicts. Run tests and perform all other
    178      appropriate tests to make sure that the merge does not create
    179      havoc. Typically changes in `m4/version.m4` are problematic
    180      so check this file extra carefully.[[br]][[br]]
    181   i. Commit changes to the trunk branch.
    182 {{{
    183 svn commit -m "Merged release A.B to the trunk."
    184 }}}
    185  1. Prepare the minor branch for the first patch release [[br]][[br]]
    186   i. Update version number in `m4/version.m4`. Locate and change the
    187      below line
    188 {{{
    189 MY_VERSION_early([A], [B], [1], [true])
    190 }}}
    191   i. Add an entry in `NEWS`
    192 {{{
    193 version A.B.1 (released NOT YET)
    194 }}}
    195      The date is set when version A.B.1 is released. [[br]][[br]]
    196   i. Commit changes to the repository,
    197      `svn ci -m "Bumping VERSION to A.B.1"` [[br]][[br]]
    198 
    199 
    200 == Patch release procedure ==
    201 
    202 This section describes what to do when publishing a patch release A.B.C.
    203 
    204  1. Make sure that all commits are performed into to the branch, such
    205     as bumping version number(s) (`configure.ac`), update `NEWS`. [[br]][[br]]
    206   i. Update the release version number in `m4/version.m4`. Locate and change the
    207      below line
    208 {{{
    209 MY_VERSION_early([A], [B], [C], [false])
    210 }}}
    211      Confirm `YAT_LT_VERSION_INFO` and add an entry in list of versions.[[br]][[br]]
    212   i. Set the date for the new release in `NEWS`
    213 {{{
    214 version A.B.C (released 27 June 2007)
    215 }}}
    216     Make sure that the items in `NEWS` cover all important bug fixes of the
    217     release. [[br]][[br]]
    218   i. Commit changes to the repository, `svn ci -m "Preparing release A.B.C"`
    219      [[br]][[br]]
    220  1. Update copyright statements with command:
    221 {{{
    222 make copyright
    223 }}}
    224  Examine the updates and commit changes with `svn ci -m "updating copyright statements"`.
    225  For this step [http://dev.thep.lu.se/svndigest svncopyright] is obviously needed.[[br]][[br]]
    226  1. Needless to say, make sure that the program is in a state to be
    227     released; make sure that all the tests pass, test the distribution
    228     package, and perform all other release tests you think is
    229     appropriate:[[br]][[br]]
    230     Run
    231 {{{
    232 make release-tag-upload
    233 }}}
    234     Fix potential problems.[[br]][[br]]
    235  1. Update SubversionCheckout and [wiki:WikiStart WikiStart][[br]][[br]]
    236   i. In section '''yat ''latest release'' ''' update link to
    237      `[source:tags/A.B.C/NEWS NEWS]` and modify the svn commands to
    238 {{{
    239 svn checkout http://dev.thep.lu.se/yat/svn/tags/A.B.C yat-A.B.C
    240 }}}
    241 {{{
    242 svn switch http://dev.thep.lu.se/yat/svn/tags/A.B.C
    243 }}}
    244   i. In section '''yat ''stable'' ''' update link to
    245      `[milestone:A.B.[C+1] A.B.[C+1]]`.[[br]][[br]]
    246   i. On WikiStart update reference to explicit latest version number, and `[source:tags/A.B/NEWS NEWS]`.[[br]][[br]]
    247  1. Close the milestone associated with the release, replace `head`
    248     with appropriate revision in log link, set diff to
    249     '`diff:tags/A.B.[C-1]//tags/A.B.C/`'. Create a log link,
    250     '`log:branches/A.B-stable@TAG-REVISION:head`', and diff,
    251     '`diff:tags/A.B.C//branches/A.B-stable/`', in milestone associated
    252     with next patch release.[[br]][[br]]
    253  1. Update the version list in Trac using the
    254     [http://dev.thep.lu.se/yat/admin/ticket/versions trac-admin tool].
    255     Remember to set the date.[[br]][[br]]
    256  1. Use `announcement.txt` as template and send email to libyat-users@lists.sourceforge.net
    257  1. Merge the patch release into the trunk. To avoid confusion and
    258     minimize the risk of loosing fixes, this step is only performed by
    259     the ''Merge Master''. [[br]][[br]]
    260   i. cd to a pristine trunk WC
    261 {{{
    262 cd /path/to/yat-trunk/
    263 svn update
    264 svn status -q
    265 }}}
    266   i. Merge changes into trunk. In this example the diffence between a
    267      minor release tag and the first patch release tag is merged into
    268      the trunk WC
    269 {{{
    270 svn merge ^/branches/A.B-stable
    271 }}}
    272   i. Resolve all conflicts. Run tests and perform all other
    273      appropriate tests to make sure that the merge does not create
    274      havoc. Typically changes in `m4/version.m4` are problematic
    275      so check this file extra carefully.[[br]][[br]]
    276   i. Commit changes to the trunk branch.
    277 {{{
    278 svn commit -m "Merged patch release A.B.1 to the trunk."
    279 }}}
    280  1. Prepare the minor branch for the next patch release [[br]][[br]]
    281   i. Update version number in `m4/version.m4`. Locate and change the
    282      below line
    283 {{{
    284 MY_VERSION_early([A], [B], [C+1], [true])
    285 }}}
    286   i. Update the interface version number in `m4/version.m4`. Locate and change the
    287      below line
    288 {{{
    289 m4_define([YAT_LT_VERSION_INFO], [c:r+1:a])
    290 }}}
    291      i.e., only raise the revision number since the interface will not
    292      change. See the
    293      [http://www.gnu.org/software/libtool/manual/html_node/Versioning.html#Versioning libtool manual] for details.[[br]][[br]]
    294   i. Add an entry in `NEWS`
    295 {{{
    296 version A.B.[C+1] (released DATE)
    297 }}}
    298      The date is set when version A.B.[C+1] is released. [[br]][[br]]
    299   i. Commit changes to the repository,
    300      `svn ci -m "Bumping VERSION to A.B.[C+1]"` [[br]][[br]]
     1This document has moved to [source:branches/0.11-stable/README.developer]