[Box Backup-dev] wiki page changes

[Stefan Norlin]

> But then the 0.10 release branch/tag also had a last minute fix merged 
> into it which confuses things. :) A common way projects handle  releases 
> is to branch the trunk into a maintenance branch for that  codeline. eg. 
> maintenance/0.11. Then any last minute fixes can be  added to this. When 
> the tarballs are actually cut this is copied to  RELEASES/0.11. Then if 
> any serious bugs are found before 0.12 is ready  they can be fixed on the 
> maintenance/0.11 branch and a 0.11.1 cut from  it.

For what it's worth...

We use Perforce for SCM using the mainline model as described here.

http://www.perforce.com/perforce/bestpractices.html

Basically all development is done in project branches (sometimes in
one instance, sometimes in multiple, personal, ones), then everything is
merged into the mainline (trunk) from which a release branch is created
when it is time for release. All testing and "last-minute" fixes are done
in the release branch and then a label is set when a release is done.

I do not know if it is relevant or merely confusing... just wanted to share
something that we have been using successfully for a few years now on
multiple different projects with 1-4 developers on each project.

Also we use the version syntax major.minor.patchlevel.build, like 
2.0.1.9878,
where the build number is always unique and basically the unique "change" 
number
provided by perforce. This way we always now exactly from where a special
build origins. The version is generated, added to a include file and 
compiled
into the build by the build script. So, if we "find" a binary laying around 
we can
also always tell exactly what version the binary is and locate the origin in 
the
tree of branches.

Stefan