> please excuse if this is a double post. It seems earlier posts have failed. > > What is the recommneded practise for building an incremental release without > pulling in incomplete code changes in the main trunk? > What do you mean by "incremental release"? It sounds to me like a release from a development effort that keeps going. In this case, it depends on what you intend to do with it. If the idea is to throw it out there for user examination, then it's less important than if you intend to have customers use it for some time.
Our practice was to cut a branch for each release, make bugfixes where relevant, and merge them to appropriate branches. > Some have suggested that we never branch and merge but simply tag individual > files associated with each implemented change to be included in the next > release so that each of these may be pulled specifically. Do you see any > issues with this approach? > This implies that the release, once shipped, will never be changed. If there are going to be any changes, you'll need a branch to avoid including later changes, which may be unready, or not what that customer wants, or simply functionality you don't want to send with this release. > The docs seem to describe branching and merging as an approach to use. Are > people successful with this? > Very. > DO you make releases off a branch and then merge it into the trunk and then > make another branch for the next release? > Here's how we did it. The trunk was for main development. Periodically (ideally every six months, but this tended to slip) we would cut a release branch. At that time, new functionality was supposed to stop, although it's really not possible to time things so all the new functionality is ready at the same time, so there was generally work going on after the branch cut (while other people, who had finished their pieces for the release earlier, were working on next release's functionality on the trunk). When changes were made in the release, they were merged to the trunk. These included finishing up new functionality and bugfixes. While we did continuous testing, it was by no means perfect, and there were bugs that were best eradicated in an environment with no new functionality. > Do you make one branch for each release or branch and merge for each change > request that is to be included in the next release? > One branch per release. This also allowed us to support customers with previous releases (unfortunately necessary for us). David H. Thornley | If you want my opinion, ask. [EMAIL PROTECTED] | If you don't, flee. http://www.thornley.net/~thornley/david/ | O- _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs