"Fossies" - the Fresh Open Source Software Archive

Member "SAOImageDS9/tcllib/devdoc/devguide.html" (13 Nov 2019, 1897 Bytes) of package /linux/misc/ds9.8.1.tar.gz:


As a special service "Fossies" has tried to format the requested source page into HTML format using (guessed) HTML source code syntax highlighting (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file.

    1 <!- Guide for Tcllib developers -->
    2 
    3 <h1>Guide for Tcllib developers.
    4 </h1>
    5 <hr>
    6 
    7 <h2>CVS Repository
    8 </h2>
    9 <table><tr><td valign=top>
   10       <!-- The local source of this image is
   11         tcllib/devel/cvs.branches.*
   12     -->
   13       <img src="http://sourceforge.net/dbimage.php?id=2221">
   14 </td><td valign=top><p>
   15 
   16 The CVS repository for Tcllib contains two main branches, the HEAD for
   17 development, and RELEASES as the staging area for official
   18 releases. At RELEASES the minor branches containing the various
   19 official releases are anchored at.
   20 </p></td></tr></table>
   21 
   22 <p>All the branches are of interest to the developers for
   23       Tcllib. Ongoing development happens in HEAD, which can be
   24       unstable or may not work at all. Whenever a developer considers
   25       a piece of code, or module, he is responsible for as
   26       sufficiently stable she has to perform an internal release which
   27       merges this part from HEAD into RELEASES. Tools to help with
   28       this will be provided.
   29 </p>
   30 
   31 <p>The branches for the official releases of tcllib are of interest to
   32       a developer because it is expected that fixes for important bugs
   33       not only go into the HEAD branch but also into the release
   34       branches for the release they were found in and all releases
   35       following that one. This is to allow the release manager to
   36       create patch releases of existing releases distributing important
   37       bugfixes as well.
   38 </p>
   39 
   40 <p>Version numbers for modules are handled as described below. This
   41       way of handling them was chosen so that the modules in the
   42       development branch always uses version numbers different from
   43       the version numbers in the official releases made so far.
   44 </p>
   45 <ul>
   46 <li>Whenever an internal release of a module FOO is done, the
   47     developer performing this internal release has to increment
   48     the version number of the module <b>after</b> the release was
   49     executed.
   50 </ul>