At 01:16 PM 6/10/97 -0700, you wrote:

promotion model as described in http://www.perforce.com/perforce/life.html? Any hidden surprises discovered (good or bad)?

Yes, sort of. The branch line we have recently started using at Unwired Planet is taken from there, and uses the model: mainline ---------------------------------------> || || \\ ==============2.0 maintenance line ------------> || || || || || 2.0.3 line --------> || 2.0.2 line -------------------> 2.0.1 line -------------------------------> (Boy, I hate ASCII art.)

People normally put code that they wanna check in, into 'mainline'. (We actually have a directory called //depot/mainline that all the source sits under.)

The first release checked into Perforce (a month or two ago) was 2.0.1, checked into both "2.0maint" and its child branch, "2.0.1".

We're currently making our first patch, with the bug fixes getting checked into "2.0maint" (the 2.0 maintenance branch). When we're closer to calling it "done" we'll make a child branch called "2.0.2" (or the like) and pull the changes over.

Over time, we will allow changes to the "2.0maint" branch that aren't destined for the next maintenance release (e.g. "2.0.6" bug fixes can be checked into 2.0maint as "2.0.3" is being staged for release) but not yet. It's more important to get people used to the mantra: "If I don't know where it goes, it goes into the mainline; if I want it to go into the patch we're making now, it goes into 2.0maint." As the users become more comfortable with the basics we'll have bug fixes specific to a particular patch/release go into that release line (and integrated back into 2.0maint and the mainline).

Part of the reason for holding off is that I want people to get comfortable with "p4 integrate/p4 resolve" across *one* line, before having them start doing integrations that go to the mainline (two branches away).

-Jeff Bowles