ProFTPD is an open development, free software (GPLed n' everything)
ongoing project.

In as much, I invite other developers who are interested in either fixing
bugs, adding features, or redesigning my oversights to get involved.  Be
it a simple patch or a complete rewrite/addition of a module, I welcome
ALL assistance.

The ProFTPD source tree is completely managed by CVS (a front-end to RCS),
another excellent piece of free software.  A *small* group of maintainers
maintain the tree, however due to the capabilities of CVS, just about
anyone with the interest and time can get involved, with minimal effort on
the maintainer's part.  Small patches (i.e. bug fixes) don't need to be
incorporated via CVS, they can simply be mailed to the developer's mailing
list, and if accepted will be patched into the next appropriate patch
level release (see below for more info).  More complicated develoment
efforts will need to register with the maintainer team and have a CVS
development branch allocated.  In order to work on the cooperative ProFTPD
effort, you will need ssh and cvs (we utilize ssh instead of rsh in order
to allow distributed cvs checkout, updates and merges). 

Source Tree
===========


1. Naming convention.


  major.minor.maintenance[pl[patchlevel]]

  ProFTPD normally exists as two top level source trees, one for
  the production server and one for development server (read: less
  stable).  Even numbered minor versions are production releases, while
  odd numbered minors are development.  This versioning corresponds to
  the CVS tag names:

  R1_4_5       = Production Version 1.4.5
  devR1_5_2pl3 = Development Version 1.5.2 patchlevel 3


  Version numbers are completely unrelated to RCS source file revision
  numbers (seen in the $Id: DEVELOPMENT,v 1.4 1997/06/05 16:57:34 flood Exp $ lines at the top of source files).  These
  revision numbers are, to a great extent, managed completely by
  CVS.

2. Developer branches/patch level branches

  During the normal course of development, a number of "patchlevel"
  revisions will be made.  Once the maintenance team decides that
  either a) critical patches are available in patchlevel source
  trees or b) enough patches are available to enhance the product,
  the newest (highest number) patchlevel revision will be merged up
  into a maintenance version.  As illustrated by the following
  CVS tree:

  devR1_5_3
     \
      \
    devR_1_5pl1 -> devR_1_5pl2 -> devR_1_5pl3
                              
  devR_1_5pl3 gets merged into a new maintenance release appropriately
  versioned "devR1_5_4".  This process of merging patchlevel revisions
  into mainstream versions can be very rapid, or take a significant
  period of time, depending on the overall product stability and
  content of patches that make up each patchlevel revision.  Patchlevel
  revisions are not widely distributed, but are available for end-users
  to run (at their own risk!)

  In order to reduce possible source conflicts each developer using
  CVS is issued a "developer" CVS branch, wherein the CVS tag
  for their private branch will be postfixed with 'd' and
  a sequence number (i.e. dev1_5_4d1).  Once a developer (or devlopers)
  have completed work on their branch, the CVS maintainer team will
  be notified and the branch will be merged into the next available
  patchlevel revision (pending testing and analysis of course).
  Developer CVS branches may also be based upon a patchlevel revision,
  depending on the nature of the planned modification (and the estimated
  time of completion).  Developer branches are not to be made publically
  available, due to the nature that they are most likely highly volatile
  and have not yet been approved for merging into a patchlevel release.

  In as much, the following diagrams what a typical ProFTPD CVS tree
  might look like (with comments).  Such a diagram will be made available
  to the general public via a finger service.

  R1_0_3     [1.0.3]                  (current production version)
     |------- R1_0_3d1                (private developer branch)
     |------- R1_0_3pl1 [1.0.3pl1]    (latest patchlevel version)
     |
  devR1_1_0  [1.1.0]                  (current development version)
     |------- devR1_1_0d1             (private developer branch)
     |------- devR1_1_0d2             (private developer branch)
     |------- devR1_1_0pl4 [1.1.0pl4] (latest patchlevel version)
         |------ devR1_1_0pl4d1       (private developer branch)

  As illustrated, once work on R1_0_3d1 has been completed and
  accepted by the CVS maintainers, it will be merged into a new
  patchlevel (R1_0_3pl2).  Other patches may accompany it.  Eventually,
  depending on conditions, the full production version will be replaced
  as R1_0_4 by the latest patchlevel.

  On the development version side, the private branches directly
  underneath devR_1_0 will also eventually be merged into a patchlevel
  version.  The theoretical current patchlevel (pl4) is waiting
  on completion of the developer branch underneath it.  Once this
  branch is completed, it will be merged up to form devR1_1_0pl5.

3. Code Freezes/Feature Freezes

  At some point in the development cycle, a decision will be made to
  "freeze" further feature development in development source trees,
  and concentrate all new patchlevels/maintenance releases on bug fixes.
  At this point, significant product testing and analysis will occur
  (and probably quite a few revisions :-)).  Once the development product
  has been adequately tested, the entire tree will be moved up into 
  the production area, and the production version's minor number
  incremeted by one.

  For a period of time after the introduction of a new minor version
  production server, no further effort will be spent on a new 
  development server.  Instead, efforts will be concentrated on fixing
  any remaining "buglets" (hopefully not many!) in the production version.

  Again, once the code has "settled" in the production area, a new
  development tree will be spawned from the stable production version so
  that work may continue on adding new features, breaking existing
  features, and the like. :-)  While a development cycle is in full
  swing, work on the production tree should be limited to bug fixes 
  (in order to avoid introducing new bugs).

4. Summary

  I know this may seem like overkill, but it's necessary to have a
  good set state of rules/documentation/etc in order for open
  distributed development not to become a nightmare (as far as source
  control).  Remember that the end-user sees nothing except for the
  typical "major.minor.maintenance" version numbers, with the
  exception of those "bleeding-edge" individuals who wish to run
  patchlevel versions.  An understanding of the CVS tag names and
  trees is only necessary for those wishing to make a large development
  contribution.  For those submitting minor bug fixes via standard patch
  files, the maintenance team will handle the CVS work necessary to
  get submissions into the next patchlevel or maintenance version
  source tree.
