[p4] Question about re-using branches

Stephen Vance steve at vance.com
Fri Mar 21 16:44:32 PDT 2008


A "single release branch" is a valid release branching model for 
long-lived, continuously evolving software. Even changes to the release 
branch that you don't want migrated to main should be integrated and 
then resolved with "accept yours" so that they don't need to be 
revisited in the future. Selective integrations are good for this.

A common implementation of the type of branching strategy you are 
talking about actually involves three branches: main, qa, and release. 
Qa branches off of main, release branches off of qa. You will typically 
use the "copy up, merge down" heuristic that Laura Wingerd espouses in 
Practical Perforce.

Separate release branches are better for the shrinkwrap model, but I 
doubt that fits you if you are doing this weekly.

Steve

Nau, Mike wrote:
> Hello Perforce Users,
>
> We have a development team interested in re-using a common release branch. 
>
> Assume our current development model is to integrate our mainline to a release branch once a week at 2pm each Friday. This code is usually released to production every Tuesday @ 5pm. The time between Friday @ 2pm and Tuesday @ 5pm is spent addressing any issues found during final testing - these changes are made on the release branch and integrated back to the mainline. Development continues on the Main line prepping for the next release. 
>
> So we end up with quite a few release branches throughout our development season. This can lead to confusing amongst out development team when trying to identify what the latest release branch is. 
>
> The general rule of thumb is changes submitted to a release branch should be merged back to the main line, but there are times this is not the case. For example when a release needs a quick fix and a more elegant solution is provided in the main line. 
>
> The development team has proposed reusing a single release branch (assume Release-2007) to handle these weekly releases. In order to cleanly replicate the status of the mainline to an existing Release-20007 branch we would have to delete (p4 delete) the Release-2007 branch first and then do a force integration from Main to Release-2007 (since the release branch might have changes that were never merged back to the main line). 
>
> The reasons for wanting to re-use a single release branch instead of spawning a new branch for each release are tied to minimizing confusion around which branch represents the current release. With a single release branch, the team can always easily find where the latest released code is. 
>
> Technically we could make a single release branch work, but it doesn't feel like the right thing to do? It leads to the following problems:
>
> - It's tougher to trace the actual changes that went in to a specific release since the release codeline is a series of deletes, forced integrates, actual changes.
> - It's tougher to ensure that changes submitted to the release branch were actually merged back to main (dilutes the effectiveness of p4 interchanges). 
> - Patches to previous releases must be handled as a branch of a branch since the release branch will have been overwritten by the current release. 
>
> Anyone have any thoughts on this? 
>
> Thanks,
> -Mike
>
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>
>   

-- 
Stephen Vance
www.vance.com



More information about the perforce-user mailing list