Changes between Version 1 and Version 2 of pm-svn-releases


Ignore:
Timestamp:
Sep 18, 2006 7:19:57 PM (15 years ago)
Author:
andreasw
Comment:

first version

Legend:

Unmodified
Added
Removed
Modified
  • pm-svn-releases

    v1 v2  
    77== One-Time Steps ==
    88
    9 First you want to make sure that the directories "trunk", "stable", and "releases" exist for your project.  An easy way to do this is to load the webpage {{{https://projects.coin-or.org/svn/YourProject}}} (such as https://projects.coin-or.org/svn/BuildTools).  This lists the base directories in your project.
     9First you want to make sure that the directories '''trunk''', '''stable''', and '''releases''' exist for your project.  An easy way to do this is to load the webpage {{{https://projects.coin-or.org/svn/YourProject}}} (such as https://projects.coin-or.org/svn/BuildTools).  This lists the base directories in your project.
    1010
    11 If a directory, say {{{releases}}}, does not yet exist, you can create it directly in the svn repository with the svn command {{{mkdir}}}, giving it the full URL.  For example:
     11If a directory, say {{{releases}}}, does not yet exist, you can create it directly in the svn repository with the {{{svn mkdir}}} command, giving it the full URL.  For example:
    1212
    1313{{{
     
    1717
    1818------------------------
     19
     20== {{{stable}}} Branchs ==
     21
     22The idea of a {{{stable}}} 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 the code.  You start with a version that you think is good enough to be made "official".  Later, you update the code in a particular {{{stable}}} branch, for example to include bug fixes, or because you add some improvements.  Typically, when you fixed a bug reported by a user, you would fix it in the corresonding stable release, and tell the user how to get it.  When it seems to work, you should probably make a new release (see below).
     23
     24Note: We strongly [https://projects.coin-or.org/CoinTLC/wiki/VersionsAndReleases suggest] to create a new stable branch when the user interface for your code changes in a way, so that users of your code would have to change their code in order to use the new code.  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.
     25
     26
     27=== Creating a new {{{stable}}} branch ===
     28
     29You usually create a new stable branch, with a version number {{{x,y}}}, say {{{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 releases the current {{{trunk}}} version in the repository as a new stable branch.
     30
     31A new {{{stable}}} branch with the chosen version number is create in the repository, using the {{{svn copy}}} command.  In order to create stable branch {{{2.3}}} from {{{trunk}}} you could use
     32
     33{{{
     34svn copy https://projects.coin-or.org/svn/YourProject/trunk \
     35           https://projects.coin-or.org/svn/YourProject/stable/2.3 \
     36           -m "Creating new stable branch 2.3 from trunk (rev 533)"
     37}}}
     38
     39'''NOTE: In the commit message you should always record the subversion revision number from which you created the new branch.'''  This information is essential for merging and some other repository operations. To find out the revision number, you can use the {{{svn info}}} command.  For example, to determine the revision number in the above example, you could have used
     40
     41{{{
     42svn info https://projects.coin-or.org/svn/YourProject/trunk
     43}}}
     44
     45and looked at the line that starts with "{{{Revision:}}}".
     46
     47=== Updating the {{{stable}}} branch ===
     48
     49To change the content for a stable branch you work with it as usually: creating a local copy of the code in that branch, making changes there (directly by editing, or by using {{{svn merge}}} to include changes made in a different version in the repository, such as {{{trunk}}}), and finally submitting the changes back to the repository.
     50
     51---------------------
     52
     53== The {{{release}}} tags ==
     54
     55The {{{release}}} directory is the place where a user can find particular, numbered releases.  The tarballs distributed on the COIN-OR website are created from those releases.  It is mandatory that by checking out a release from this place in the repository always proves the identical code, so that restore older versions is possible (for example for reproducing bugs).  In this context you need to be careful if you use {{{svn:externals}}}.  '''Once a release has been created it must not be changed!'''
     56
     57=== Creating a new {{{release}}} ===
     58
     59Typically, you would have a version of your code in a stable branch, say 2.3, which you now want to make an official release.
     60
     61'''If you are using Externals''':  Before creating the new releaes from the current version in the stable branch, '''you need to make sure that all {{{svn:externals}}} are pointing to ''releases'' of the dependencies''' so that your release can be recreated exactly at any point in time, even if the development of the dependencies progressed.  So, please make sure that all URLs in your {{{Externals}}} file are pointing to something in the {{{release}}} directory of the dependencies.  Also, make sure that the externals are indeed set according to the file content (verify with {{{svn pget svn:externals https://projects.coin-or.org/svn/YourProject/stable/2.3}}}).
     62
     63To create a new release, say 2.3.6, you use the {{{svn copy}}} command:
     64
     65{{{
     66svn copy https://projects.coin-or.org/svn/YourProject/stable/2.3 \
     67           https://projects.coin-or.org/svn/YourProject/releases/2.3.8 \
     68           -m "Creating new release 2.3.8 from stable/2.3 (rev 567)"
     69}}}
     70
     71Again, it is a very good idea to log the subversion repository revision number in the commit message.