RE: Branching strategy - Feature vs Release

Please see the comments between the =========='s

On Wed, 2006-11-08 at 18:00, Richard Gundersen wrote:

> In my last job, the systems I looked after were used in 20+ countries.
So,
> one copy of the system, with lots of customisations. Each country
would have
> their own changes. Sometimes they would be cosmetic and low risk.
Other
> times, they would say 'Spain has a new law regarding X. The system
must
> support this law on 1st August 2007'. The application change cannot
however
> be released before then. It must be released at midnight, 31 July
2007,
> otherwise the system is operating illegally.
>
> At the same time, Germany has another change. Theirs will take a long
time
> to implement so development must also be started now. But theirs must
not be
> released until 1st October 2007.
>
> If all development is done on one trunk branch, then at some point I
have to
> tell Germany that because Spain MUST have their change, I have to
release
> their change too. I know what will happen - Germany will stop using
the
> system.

>>>That's only true if you add an unnecessary constraint that your
>>>releases have to be directly from the trunk. If you tag/release
>>>from branches you can support any number of versions concurrently.

=============================================================
I'm not sure I understand. I want to keep these two changes separate
from each other so they can be released independently. If they are both
developed on the trunk, I can't separate them. Are you saying have a
release branch for each change? In order for them to remain separate,
development for each change would have to START on the release branch.
If the release branch this development started on was for another
release that had already been agreed (it contains other functionality
too), that release will have to wait until the development of the
feature is finished, otherwise the release will include unfinished work.
If this is the only reason for having the branch, it's a feature branch.
And what's more, it might have been branched off an unstable trunk that
was in no fit state for production.
=============================================================

> Using feature branches, when it comes to 31 July 2007, I just merge
their
> change into the trunk and release it. (OK, this would be done maybe a
week
> or two in advance for testing purposes). Germany isn't affected.
Everyone is
> happy.

In subversion the difference between a branch and trunk (and
tags for that matter) is completely arbitrary - it's just a
directory name and the capabilities are all the same. I think
it makes sense to use the trunk for the thing you least want
to keep track of. For a lot of projects, I'd expect that to
be where to put/get today's new changes. For QA and releases
you are going to have to track specific names anyway.

=============================================================
I think my reply to the point above proves the case for a stable trunk.
=============================================================

-- 
  Les Mikesell
   lesmikesell@gmail.com
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
*** Disclaimer *** 
This electronic communication is confidential and for the exclusive use of the addressee. It may contain private and confidential information. The information, attachments and opinions contained in this E-mail are those of its author only and do not necessarily represent those of London Scottish Bank PLC or any other members of the London Scottish Group. 
If you are not the intended addressee, you are prohibited from any disclosure, distribution or further copying or use of this communication or the information in it or taking any action in reliance on it. If you have received this communication in error please notify the Information Security Manager at ISM@London-Scottish.com as soon as possible and delete the message from all places in your computer where it is stored. 
We utilise virus scanning software but we cannot guarantee the security of electronic communications and you are advised to check any attachments for viruses. We do not accept liability for any loss resulting from any corruption or alteration of data or importation of any virus as a result of receiving this electronic communication. 
Replies to this E-mail may be monitored for operational or business reasons. London Scottish Bank PLC is regulated by the Financial Services Authority.
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org