0) prepare HEAD for new release
                a) move code out from behind LDAP_DEVEL as appropriate
                for new release
                b) unifdef code as appropriate for new release
          Note: this is done on a case by case bases, some cases deferred
          until beta/GA stages.  But by GA, most everything in the new release
          should be main line (not behind ifdefs).
        1) lay a branch-point tag in HEAD, e.g.,
        cvs tag OPENLDAP_REL_ENG_2_4_BP
        2) create a branch off this tag.
        cvs tag -b -rOPENLDAP_REL_ENG_2_4_BP OPENLDAP_REL_ENG_2_4
        3) lay a merge-point tag in HEAD, e.g.,
        cvs tag -rOPENLDAP_REL_ENG_2_4_BP OPENLDAP_REL_ENG_2_4_MP

         Note: At this point, the difference between the branch point and
        merge-point is nil.

        4) checkout the release branch
        cvs co -dre24 -rOPENLDAP_REL_ENG_2_4_BP ldap

        5) update re24 as appropriate for the release
                a) update version.var and other version stuff, add
                empty CHANGES file
                b) replace README, INSTALL, etc., with release version
                (copy in from prior release, edit as needed).
                c) remove from files not intended for release
                d) ...

        7) when ready for release
                a) update CHANGES and version.var
                b) lay release tag
                cvs tag OPENLDAP_REL_ENG_2_4_0ALPHA

            Note: pre-releasing testings can be inserted as needed before a)
           or after b.  If after b, any changes resulting from this testing
           may cause files (CHANGES, version date, and code) to be updated.
           Just repeat b, overwriting the old tag (e.g., add -F).

                c) update the merge point
                cd head; cvs tag OPENLDAP_REL_ENG_2_4_MP

                Note: HEAD is a moving target. It is good to have a
                HEAD checkout that is only as up to date as what's
                been merged into (or at least considered to be merged
                into) the RE branch, so that this tag get's laid
                down appropriately for the next merge.  Also, when
                step 5 is done over an extended period of time, it
                may be appropriate to move the merge point forward
                to help in bring in new changes.  How to use the
                merge point is discussed in B) below.

                d) notify Foundation when COMPLETELY ready for release