|To create a new release engineering branch:
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
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