RE: Release/Branching best practices

Thanks for your response Ian.

Currently we do something like in picture at the bottom. We spawn
projects (p1222) as branches off of releases (prd_7.2.2).

Releases are cut from the trunk. Bugs and projects are moved to the
trunk when they are complete and approved. Our issue is that we have
trouble identifying what is a part of each release. For instance, if we
had 12 bugs come from the bugs branch and 2 projects come in then cut
our release and moved 3 bugs in to the trunk and then found issues with
the release. We fix the release and then merge back to the trunk but
this starts to get convoluted as to which commits belong to which
release. Our current solution is to require that developers specify in
their log messages (enforced via a pre-commit hook) which release their
fix/project belongs to. This should help us scrape the log messages to
identify which projects and bugs went into a release.

Our other issue is keeping the bugs branch and trunk in-synch. With each
release we merge everything over to bugs (generally this will reapply
fixed bugs and move projects over). However, there's never a guarantee
that it won't screw up the bugs team's development process.

Note: We used to have a separate QA branch to keep the trunk always
stable for spawning projects, but there's no point in doing that since
we now spawn projects off the required release branch.

 
<http://sp1/rd/scm/Help%20images/Source%20PNGs/Merge%20Outline%20Detaile
d_v3.0.png>

________________________________

From: Ian Wood [mailto:Ian.Wood@sucden.co.uk]
Sent: Wednesday, November 28, 2007 2:33 AM
To: James Oltmans; users@subversion.tigris.org
Subject: RE: Release/Branching best practices

Hi James,

This is how we do it.

We have a repo as below.

>Trunk

>Branches

>Versions

>1_0_0

>1_0_1

>Tags

>SuccessfulBuilds

>1_0_0

>1_0_0_1

>1_0_0_2

The main work is done on the Trunk. Then each month we make a Version
branch of the current months version, ( just the first three numbers,
the forth is determined by the CruiseControl machine ).

The code on this version branch is released to the test team and tested
and any bugs found are then fixed on that branch and released again.

Then when that code is released to live the changes made are merged back
to the Trunk and another branch is taken.

Indecently each time the Version branch builds successfully a Tag is
taken with the version number and a deployment script is created.

We are not finding it too burdensome, the only problem we have found is
when people make changes to the same code in both places without merging
as they go.

What are currently doing?

Best regards,

Ian

________________________________

From: James Oltmans [mailto:JOltmans@bolosystems.com]
Sent: 28 November 2007 00:55
To: users@subversion.tigris.org
Subject: Release/Branching best practices

Hello all,

Could someone point me in the right direction for finding best-practices
or software to manage releases? We are trying to use a monthly release
cycle and our current branch and merge management is becoming a bit
burdensome.

Thanks,
James

www.sucden.co.uk <http://www.sucden.co.uk/>

Sucden (UK) Limited, 5 London Bridge Street, London SE1 9SG
Telephone +44 20 7940 9400
 
Registered in England no. 1095841
VAT registration no. GB 446 9061 33

Authorised and Regulated by the Financial Services Authority (FSA) and
entered in the FSA register under no. 114239

This email, including any files transmitted with it, is confidential and
may be privileged. It may be read, copied and used only by the intended
recipient. If you are not the intended recipient of this message, please
notify postmaster@sucden.co.uk immediately and delete it from your
computer system.

We believe, but do not warrant, that this email and its attachments are
virus-free, but you should check.

Sucden (UK) Ltd may monitor traffic data of both business and personal
emails. By replying to this email, you consent to Sucden's monitoring
the content of any emails you send to or receive from Sucden. Sucden is
not liable for any opinions expressed by the sender where this is a
non-business email.

The contents of this e-mail do not constitute advice and should not be
regarded as a recommendation to buy, sell or otherwise deal with any
particular investment.

This message has been scanned for viruses by BlackSpider MailControl
<http://www.blackspider.com/>