From info-cvs-ownrr@prep.ai.mit.edu Sat Oct 14 22:01:21 1995 Date: Sat, 14 Oct 95 19:03:25 -0400 (EDT) From: woods@most.weird.com (Greg A. Woods) To: Scott Butler Cc: info-cvs@prep.ai.mit.edu Subject: Re: CVS Taginfo to do Module Release info. In-Reply-To: Scott Butler's message of "Fri, October 13, 1995 17:07:37 -0600" regarding "Re: CVS Taginfo to do Module Release info. " Reply-To: woods@most.weird.com (Greg A. Woods) X-Mailer: ViewMail (vm) Version 5.72 (beta) Organization: Planix, Inc.; Toronto, Ontario; Canada Status: OR [ On Fri, October 13, 1995 at 17:07:37 (-0600), Scott Butler wrote: ] > Subject: Re: CVS Taginfo to do Module Release info. . . . Perhaps I should describe a more complete outline of how I do releases (and how I've seen several other folks, such as the NetBSD team) do them. Here's my 10-step method: Assumptions: - one or more programmers, all of whom are trusted not to fiddle with official tags - one CVS module for this entire project (modulename) - development work proceeds on the main trunk - the tag naming scheme is "R_nn" for the final release, "R_nn_BASE" for the main trunk rev where the release branch starts, and "R_nn_BR" for the release branch itself 1. you decide to get ready to cut a new release.... - identify what fixes/features must be in this new release and schedule the changes to be done - identify what ongoing work must not be in this new release, and if possible identify the revision numbers of each file which precede those features not to be included (use in step 4) 2. finish off any missing work, if possible, or go back to step 1 3. check out a "release" working directory in which you'll tag the release - hopefully the top revision of the main trunk is close to what you want in the new release 4. using "cvs update -r filename", etc., back out any changes that shouldn't be included in the new release - do builds and tests in this release working directory as necessary to ensure things still fit together - don't do any commits from this release working directory -- if you have any changes to include that haven't yet been committed, and they are intended to be a part of the ongoing work, make them in a working directory that's current to the main trunk and commit them to the main trunk, then "update" them into the release working directory -- otherwise wait until step 7 5. create a branch point from the revisions in the release working directory - this will normally be done by "cvs tag R_nn_BASE" followed by "cvs rtag -b -rR_nn_BR modulename" 6. remove the release working directory and check out a release branch working directory - "cvs release -d modulename" -- you won't likely need it again, and it can be re-created in any case - "cvs co -r R_nn_BR modulename" 7. build, test, and fix the release as necessary -- do not procede until everything is absolutely perfect for the release - changes that are only to be made to the release must be made only in a branch working directory - changes that are to be made to both the release and need to be carried to the ongoing development must be commited to both the release branch and the trunk (this might be facilitated by committing the changes on the main trunk, then using "cvs update -j" to merge them on the release branch, and finally commit them on the release branch with a note explaining where they came from) - multiple programmers can work on the release by checking out the release branch, but there should be one official release branch working directory too -- just remember to do regular "cvs update"s in each release branch working directory and the official one too - by tests I mean those that can be done in the build directory(ies) - if you have to "ship" code at this point for testing outside of the build directories, you should tag them with "R_nn_T_nn" and do the ship from a "cvs export -r R_nn_T_nn modulename" 8. when you are ready with the release, tag it - in the official release branch working directory tag the final release with "cvs tag -r R_nn" 9. export the code and build and prepare an install file set from the exported code: - i.e. in yet another directory do "cvs export -kv -r R_nn" - build a distribution in the export directory 10. ship the product.... Of course if there's only one programmer you can merge a few of these steps together, and you can possibly even avoid the use of a release branch -- just put the release tags on the main branch. You can do this too with multiple programmers, but only if you enforce a commit freeze during which only commits for the official release can be made -- i.e. the release branch scheme is most definitely easier with multiple programmers working at an on-going project. Note that fixes to released products can either be treated as new releases from the main branch, or you can commit them to the release branch and tag them with something like "R_nn_P_nn", or you can create a patch branch from the "R_nn" position. BTW, if anyone has any further ideas, suggestions, or gotchas, etc. about these release management procedures and such, please let's discuss them! -- Greg A. Woods +1 416 443-1734 VE3TCP robohack!woods Planix, Inc. ; Secrets of the Weird