Changes between Version 20 and Version 21 of pm-svn-releases


Ignore:
Timestamp:
Feb 19, 2011 2:41:50 PM (9 years ago)
Author:
stefan
Comment:

replace COIN by COIN-OR; fix a typo

Legend:

Unmodified
Added
Removed
Modified
  • pm-svn-releases

    v20 v21  
    11= Suggestions for Handling Stable Versions and Releases =
    22
    3 This page describes how the [https://projects.coin-or.org/CoinTLC/wiki/VersionsAndReleases policy for versioning suggested by COIN] can be implemented within the subversion repository for your project. You might want to first read the page on [wiki:pm-svn-branches understanding branches and tags], or other pages for [wiki:pm-svn understanding subversion]. Below, the string ''!YourProject'' is to be replaced by the name of your project.
     3This page describes how the [https://projects.coin-or.org/CoinTLC/wiki/VersionsAndReleases policy for versioning suggested by COIN-OR] can be implemented within the subversion repository for your project. You might want to first read the page on [wiki:pm-svn-branches understanding branches and tags], or other pages for [wiki:pm-svn understanding subversion]. Below, the string ''!YourProject'' is to be replaced by the name of your project.
    44
    55== Overview ==
     
    4242=== Moving Branches ===
    4343
    44 Some of the existing COIN projects had a development branch {{{branches/devel/}}}.  With the transition to the new release policy described here, this branch should now become {{{trunk/}}}.  The easiest way to do this is to first delete the old {{{trunk/}}} directory in the subversion repository (assuming that the previous "stable release" content has been copied into an appropriate place in {{{stable/}}} and/or {{{releases/}}}), and then to move {{{branches/devel/}}} to {{{trunk/}}}:
     44Some of the existing COIN-OR projects had a development branch {{{branches/devel/}}}.  With the transition to the new release policy described here, this branch should now become {{{trunk/}}}.  The easiest way to do this is to first delete the old {{{trunk/}}} directory in the subversion repository (assuming that the previous "stable release" content has been copied into an appropriate place in {{{stable/}}} and/or {{{releases/}}}), and then to move {{{branches/devel/}}} to {{{trunk/}}}:
    4545
    4646{{{
     
    5454== Working with Stable Versions ==
    5555
    56 The idea of a {{{stable/x.y/}}} branch is that you maintain a stable line of your code here that can be used by a user who wants to be up-to-date with your "official" version of version {{{x.y}}}.  You start with a version that you think is good enough to be made "official".  Later, you may update the code in a particular {{{stable/x.y/}}} branch to include bug fixes, or because you've made some improvements.  Typically, when you fix a bug reported by a user, you would fix it in the corresonding stable release and tell the user how to get it.  When you're confident it works, you should consider a new point release (see below).
     56The idea of a {{{stable/x.y/}}} branch is that you maintain a stable line of your code here that can be used by a user who wants to be up-to-date with your "official" version of version {{{x.y}}}.  You start with a version that you think is good enough to be made "official".  Later, you may update the code in a particular {{{stable/x.y/}}} branch to include bug fixes, or because you've made some improvements.  Typically, when you fix a bug reported by a user, you would fix it in the corresponding stable release and tell the user how to get it.  When you're confident it works, you should consider a new point release (see below).
    5757
    5858Note: We [https://projects.coin-or.org/CoinTLC/wiki/VersionsAndReleases strongly suggest] that you create a new stable branch when the user interface for your code changes in such a way that users of your code would have to change their code in order to use the new interface.  By creating a new stable branch, a user will not find any bad surprises when updating his/her local copy of a stable branch, and can instead switch to a new stable branch later, whenever (s)he is ready.
     
    6363You usually create a new stable branch with a version number {{{x.y}}} (''e.g.'', {{{2.3}}}) from some version of your code that exists in the repository.  Typically, you would have been working in {{{trunk/}}} (where the active development takes place), and want to release the current {{{trunk/}}} version in the repository as a new stable branch.
    6464
    65 '''It is strongly recommended''' that you use the {{{prepare_new_stable}}} and {{{commit_new_stable}}} scripts provided in !BuildTools. These scripts will automatically make the changes to configuration files and externals required to conform with COIN standards for stable branches.
     65'''It is strongly recommended''' that you use the {{{prepare_new_stable}}} and {{{commit_new_stable}}} scripts provided in !BuildTools. These scripts will automatically make the changes to configuration files and externals required to conform with COIN-OR standards for stable branches.
    6666The first script, {{{prepare_new_stable}}}, does the following things for you:
    6767
     
    113113Typically, you would have a version of your code in a stable branch, say {{{stable/2.3/}}}, which you now want to make an official release.  '''Remember, it is mandatory that one can recreate exactly the same version in the future''', ''i.e.'', you should not change anything in a point release after you set it up.
    114114
    115 '''It is strongly recommended''' that you use the {{{prepare_new_release}}} and {{{commit_new_release}}} scripts provided in !BuildTools. These scripts will automatically make the changes to configuration files and externals required to conform with COIN standards for releases (including libtool library versioning).
     115'''It is strongly recommended''' that you use the {{{prepare_new_release}}} and {{{commit_new_release}}} scripts provided in !BuildTools. These scripts will automatically make the changes to configuration files and externals required to conform with COIN-OR standards for releases (including libtool library versioning).
    116116The scripts have extensive help texts.
    117117