Changes between Version 7 and Version 8 of pm-svn-releases

Timestamp:

Sep 19, 2006 7:27:01 PM (14 years ago)

Author:

andreasw

Comment:

minor additions

pm-svn-releases

@@ -5 +5 @@
 == Overview ==
 
-The overall philosophy of the COIN-OR versioning and release system is to specify standard procedures for maintaining the code base of COIN-OR projects that allow various groups of users to 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/}}}. 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 specified points in time, specific versions can be slit off from this main development line for the purpose of implementing special features or declaring a '''stable release''' (see below). The directories {{{branches/}}} are optional directories that can contain version implementing or testing experimental features. The directory {{{tags/}}} is for storing fixed and named snapshots of code for future reference. No new code should ever be committed to the {{{tags/}} directory. The use of the {{{stable/}}} and {{{releases/}}} directory is to create stable versions of the project for users to download and other projects to link to. This explained in more detail next.
+The overall philosophy of the COIN-OR versioning and release system is to specify standard procedures for maintaining the code base of COIN-OR projects that allow various groups of users to 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/}}}. 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 specified points in time, specific versions can be slit off from this main development line for the purpose of implementing special features or declaring a '''stable release''' (see below). The directories {{{branches/}}} are optional directories that can contain version implementing or testing experimental features. The directory {{{tags/}}} is for storing fixed and named snapshots of code for future reference. No new code should ever be committed to the {{{tags/}}} directory. The use of the {{{stable/}}} and {{{releases/}}} directory is to create stable versions of the project for users to download and other projects to link to. This explained in more detail next.
 
 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 should be 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 prupose). In subversion, such a two-digit version is not frozen once copied to {{{stable/}}}. It is intended to continue evolving 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 into {{{trunk/}}}, as appropriate (see below). 
@@ -74 +74 @@
 === Creating a New Point Release ===
 
-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.
+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.
 
-'''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}}}).
+'''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}}}, 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, 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}}}).  (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.)
 
 To create a new release, say 2.3.6, you use the {{{svn copy}}} command: