Changes between Version 10 and Version 11 of pm-svn-releases


Ignore:
Timestamp:
Oct 10, 2006 5:23:37 PM (14 years ago)
Author:
lou
Comment:

Added explanation of release.txt

Legend:

Unmodified
Added
Removed
Modified
  • pm-svn-releases

    v10 v11  
    3131== Setting up your Repository ==
    3232
    33 First, 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}}} (''e.g.'', https://projects.coin-or.org/svn/BuildTools).  This lists the base directories in your project.
     33First, make sure that the directories {{{trunk/}}}, {{{stable/}}}, {{{releases/}}}, and {{{conf/}}} exist for your project. An easy way to do this is to load the webpage {{{https://projects.coin-or.org/svn/YourProject}}} (''e.g.'', https://projects.coin-or.org/svn/BuildTools).  This lists the base directories in your project.
    3434
    3535If a directory, say, {{{releases/}}}, does not yet exist, you can create it directly in the repository with the {{{svn mkdir}}} command, giving it the full URL.  For example:
     
    4242== Working with Stable Versions ==
    4343
    44 The 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 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 it seems to work, you should consider a new release (see below).
     44The 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).
    4545
    46 Note: We strongly [https://projects.coin-or.org/CoinTLC/wiki/VersionsAndReleases 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.
     46Note: 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.
    4747
    4848
    4949=== Creating a New Stable Version ===
    5050
    51 You 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.
     51You 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.
    5252
    53 A new stable branch with the chosen version number is created in the repository using the {{{svn copy}}} command.  In order to create stable branch {{{2.3}}} from {{{trunk}}} you could use
     53A new stable branch with the chosen version number is created in the repository using the {{{svn copy}}} command.  In order to create stable branch {{{2.3}}} from {{{trunk/}}} you could use
    5454
    5555{{{
     
    7777=== Creating a New Point Release ===
    7878
    79 Typically, you would have a version of your code in a stable branch, say 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.
     79Typically, 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.
    8080
    8181'''If you are using [wiki:pm-svn-externals Externals]''':  Before creating the new release from the current version in the stable branch, '''you need to make sure that all {{{svn:externals}}}, in the version that you want to make the release, are pointing to ''releases'' of the dependencies''' so that your release can be recreated exactly at any point in time, independent of continuing development of the dependencies.  Please make sure that all URLs in your {{{Externals}}} file are pointing to something in the {{{release}}} directory of each dependency.  Also, make sure that the {{{svn:externals}}} property is indeed set according to the file content (verify with, ''e.g.'', {{{svn pget svn:externals https://projects.coin-or.org/svn/YourProject/stable/2.3}}}).  (Note: If for some reason a compatible release for a dependency does not exist, you must specify the subversion revision number, using the "{{{-r}}}" flag in the {{{externals}}} definition.)  Please read [wiki:pm-svn-externals here] for additional explanation of how to handle externals in COIN.
     
    9090
    9191Again, it is a very good idea to log the subversion repository revision number in the commit message.
     92
     93== Creating a Tarball ==
     94
     95There's one last step to actually create a tarball for a release: you need to create {{{conf/release.txt}}}.
     96The contents of {{{release.txt}}} should be a single line specifying the root of the release directory in the repository, and the version number used for the tarball.
     97For example, to create {{{YourProject-2.3.8.tgz}}}, the contents of {{{release.txt}}}
     98would be
     99
     100{{{
     101releases/2.3.8    2.3.8
     102}}}
     103
     104Once you've created this file, use {{{svn add}}} and {{{svn commit}}} to add it to the
     105{{{conf/}}} directory. The commit will take a loooong time, because the tarball is created on the spot. When the commit finishes, your tarball will be ready in the COIN
     106downloads directory.