[p4] Branching strategy for major.minor.patch versioning

[Rick Macdonald]

Steve,

This is interesting, but I can't spot where you are reducing the number 
of integrations.

.     1.0.0   1.0.1    1.1.0            2.0.0       2.1.0
.    /       /        /                /           /     .
.   /-1.0.x-----     /-1.1.x--        /-2.0.x--   /-2.1.x----
.  /                /                /           /       .
. /-1.x------------------------     /-2.x---------------------
./                                 /                     .
.--main--------------------------------------------------------

The 1.0.0, 1.0.1, etc are the released versions, and are either labels 
or actual branches, right? If you fix a bug in 1.x, and somebody 
integrates it to 1.0.x (so 1.0.2 can be released) and to the mainline 
(and potentially 1.1.x, 2.x, 2.0.x, 2.1.x), where is the savings? Or is 
it just that you have different people doing the integrations for the 
developer?

Rick

Steve Babiak wrote:
> Before a certain Perforce employee had published her book, I had
> already assembled a similar design here at AGI.  The model we use
> is a bit like the first diagram you had in your original post.
> We employ some variations that you might discover solve some of
> the issues (primarily the one that lots of integrations need to
> happen).
>
>
> First difference:
>   We have a letter representing a "variable" in the versioning.
> So, we have "main" being parent of "8.x" branch; "8.x" branch is
> parent of "8.0.x" and "8.1.x" (etc.); if needed, we can then have
> "8.0.x" be parent of "8.0.0" branch, etc. - but we usually get by
> without that (except whenever a specific customer request saying
> that they want a specific change only, built on exactly the
> version they have in their operational environment).
>
>
> Second difference:
>   To reduce number of integrations by any developer, they usually
> develop on the "8.x" branch in the above example - and even for
> most bug fixes, that will be the case.  The lead developer for
> the release then integrates the desired changes from that "8.x"
> branch into the "8.1.x" branch level.  Permissions to do changes
> at that "8.1.x" level are restricted to those who need to make
> such changes.  Every so often the "8.x" files will be drastically
> different from the "8.1.x" branch's files; in such cases, a
> developer will be given the permissions needed to make the change
> at that branch level (and then once completed, such permissions
> are taken away).  This might happen, for example, if a fix is to
> be ported to the "8.0.x" branch, and the "8.x" area has advanced
> to be a base for "8.1.x" or "8.2.x".
>
>
> Third difference:
>   A label is used to mark the file versions that were used in
> "8.0.0", "8.0.1", "8.0.2", etc. release derived from the "8.0.x"
> branch; these could also be branched - but then that increase the
> number of developer workspaces for the lead.
>
>
> The one remaining thing is to also track integrations, to be sure
> that needed changes are propagated to the appropriate codelines.
> The policy here is that for all release type branches (such as
> those being discussed earlier in this email), all changes on the
> child are integrated to the parent branch.  When the lead
> integrated into the "8.1.x" branch, notifications to integrate
> those changes into the "8.x" branch will be produced (if the
> integration needs to be performed).  Any change on the "8.x"
> branch will need to be integrated into "main" by the developer
> who made the change; they are notified of this if they neglect to
> integrate to the parent.
>
>
> So, we reduce the number of integrations that are actually
> needed; we do follow the practice of branch as late as possible
> for releases, so even the lead developer does not have too much
> extra effort in keeping the release branch's state so that it has
> all needed fixes.
>
>
> Hope that helps.
>
>
> Steve Babiak
>
>
>
>