Changes between Version 13 and Version 14 of pm-svn-releases


Ignore:
Timestamp:
Oct 15, 2006 8:50:49 PM (14 years ago)
Author:
lou
Comment:

touch up wiki formatting, Tarball Creation

Legend:

Unmodified
Added
Removed
Modified
  • pm-svn-releases

    v13 v14  
    77The purpose of the COIN-OR versioning and release system is to specify standard procedures for maintaining the code base of COIN-OR projects so that users can obtain the version of the code most appropriate for them. The recommended [wiki:pm-svn subversion] repository layout for COIN-OR projects includes the top-level directories {{{trunk/}}}, {{{branches/}}}, {{{tags/}}}, {{{stable/}}}, and {{{releases/}}}.
    88
    9 At all times, the main development line is to be contained in {{{trunk/}}}. The code in {{{trunk/}}} is not expected to be completely functional and is the "bleeding edge" of the project. At appropriate points in time, specific versions can be split off from the main development line for the purpose of declaring a '''stable release''' (see below) or implementing special features.
     9At all times, the main development line is to be contained in {{{trunk/}}}. The code in {{{trunk/}}} is not expected to be completely functional and is the "bleeding edge" of the project. At appropriate points in time, specific versions can be split off from the main development line for the purpose of declaring a stable version (see below) or implementing new features.
    1010
    11 The {{{branches/}}} and {{{tags/}}} directories may be used at the developer's convenience. Directories under {{{branches/}}} typically contain versions of the code created to implement or test experimental features. The {{{tags/}}} directory can be used for storing fixed and named snapshots of code for future reference. To maintain the utility of tags, subversion usage conventions recommend that no new code should ever be committed to the {{{tags/}}} directory.
     11The {{{branches/}}} and {{{tags/}}} directories may be used at the developer's convenience. Directories under {{{branches/}}} typically contain versions of the code created to implement and test new features. The {{{tags/}}} directory can be used for storing fixed and named snapshots of code for future reference. To maintain the utility of tags, subversion usage conventions recommend that no new code should ever be committed to the {{{tags/}}} directory.
    1212
    13 The {{{stable/}}} and {{{releases/}}} directories hold the stable versions of a project that are referenced as externals by other projects and downloaded by users.
    14 A '''stable version''' is created whenever the PM wishes to declare a new version of the project. Creating a '''stable version''' means roughly that the feature set and API associated with that particular version are frozen, but the code may continue to evolve through the application of patches to fix bugs, the addition of documentation, ''etc.'' Such a "stable version" is identified by a two-digit version number (''i.e.'', 5.1) and is associated with a similarly-named subdirectory in {{{stable/}}} created by branching (copying) the code in {{{trunk/}}} (see below for specific commands to be used for this purpose). Stable versions are not considered frozen when copied to {{{stable/}}}. It is intended that they continue to evolve and new code can be committed to subdirectories in the {{{stable/}}} directory. However, this evolution should generally consist of bug fixes and minor tweaking only---development of new features for future versions can continue at the same time in {{{trunk/}}}. Bug fixes applied to versions in {{{stable/}}} may also need to be merged back to {{{trunk/}}}, as appropriate (see below).
     13The {{{stable/}}} and {{{releases/}}} directories hold the stable versions and point releases of a project that are referenced as externals by other projects and downloaded by users.
     14A '''stable version''' is created whenever the PM wishes to declare a new version of the project. Creating a stable version means roughly that the feature set and API associated with that particular version are frozen, but the code may continue to evolve through the application of patches to fix bugs, the addition of documentation, ''etc.'' Such a stable version is identified by a two-digit version number (''i.e.'', 5.1) and is associated with a similarly-named subdirectory in {{{stable/}}} created by branching (copying) the code in {{{trunk/}}} (see below for specific commands to be used for this purpose). Stable versions are not considered frozen when copied to {{{stable/}}}. It is intended that they continue to evolve and new code can be committed to subdirectories in the {{{stable/}}} directory. However, this evolution should generally consist of bug fixes and minor tweaking only---development of new features for future versions can continue at the same time in {{{trunk/}}}. Bug fixes applied to versions in {{{stable/}}} may also need to be merged back to {{{trunk/}}}, as appropriate (see below).
    1515
    1616An important notion is that declaring a new stable version is not the same as creating a new '''point release'''. A point release is a fixed snapshot of a stable version intended for distribution in source and/or
     
    4040}}}
    4141
    42 === Moving Braches ===
     42=== 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 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{{{
     
    8585== Working With Point Releases ==
    8686
    87 The {{{releases/}}} directory is the place where a user can find particular, numbered releases.  The tarballs distributed on the COIN-OR website are created from these releases.  It is mandatory that checking out a release from this place in the repository always provides the identical code, so that it's possible to restore older versions (''e.g.'', to reproduce a bug reported by a user).  In this context you need to be careful if you use {{{svn:externals}}}.  '''Once a release has been created it must not be changed!'''
     87The {{{releases/}}} directory is the place where a user can find particular, numbered releases.  The tarballs distributed on the COIN-OR website are created from these releases.  It is mandatory that checking out a release from this place in the repository always provides the identical code, so that it's possible to restore older versions (''e.g.'', to reproduce a bug reported by a user).  In this context you need to be careful if you use {{{svn:externals}}}.  '''Once a release has been created it must not be changed! '''
    8888
    8989=== Creating a New Point Release ===
     
    107107Unless you instructed the COIN-OR website maintainer otherwise, tarballs for your project will be created automatically every night for each point release in your {{{releases/}}} directory.
    108108
    109 However, you can use an additional mechanism to create a tarball: You can create {{{conf/release.txt}}}.
     109However, you can use an additional mechanism to create a tarball: You can use a file, {{{conf/release.txt}}}.
    110110The 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.
    111111For example, to create {{{YourProject-2.3.8.tgz}}}, the contents of {{{release.txt}}}
    112112would be
    113 
    114113{{{
    115114releases/2.3.8    2.3.8
    116115}}}
    117116
    118 Once you've created this file, use {{{svn add}}} and {{{svn commit}}} to add it to the
    119 {{{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
    120 downloads directory.
     117To create this file, use {{{svn add}}} and {{{svn commit}}} to add it to the
     118{{{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 downloads directory. Subsequently, after you've created a new point release in {{{releases/}}, simply edit and commit {{{releases.txt} to trigger the creation of a new tarball.