Hi Dmitri
I agree, both strategies are very similar in the long run. I'm not too
sure which side (if any) you are favouring, but for what it's worth,
this is how I'd do the situation you described
Release 1.0 is in production (contained on the trunk)
Feature X and Feature Y are both completed. So they BOTH get merged into
the trunk, tested, released, committed to the trunk, trunk is tagged.
Trunk still reflects the state of the production server.
The big benefit of keeping X and Y on their own branches, is when you
want to release X but NOT Y (maybe Y isn't finished yet, or Y can only
be released on a certain date for some legal requirement or other
constraint).
Yes, I like to assume that I have multiple customers. This doesn't mean
multiple running versions though. In most large systems I have worked
on, there are different groups of users. Perhaps they are in different
countries, and therefore have different laws. Or, different divisions
with differing requirements. But they all use the SAME system. (The
alternative would be to give them all their own copies of the system,
but I wouldn't like to maintain that!)
-Richard
-----Original Message-----
From: colebatchd@gmail.com [mailto:colebatchd@gmail.com] On Behalf Of
Dmitri Colebatch
Sent: Monday, November 13, 2006 10:45 AM
To: Gundersen, Richard
Subject: Re: Branching strategy - Feature vs Release
Hi Richard et al,
I'm a long way behind, and have just read over this rather quickly and
wanted to point something out. If this has already been stated and I
skimmed it, ignore me.
I think everyone here will agree that it is important to know which code
is being used in production. There are two main reasons why we want
this, firstly to diagnose problems, and secondly to provide bugfixes.
In order to have access to the code that is being used in prod, we need
to do one of two things:
1. Move it somewhere
2. Make sure it doesn't change
Effectively (1) is release branching, and (2) is feature branching.
In reality, it doesn't matter. In both cases we have a branch that
contains the prod code - in (1) it is the "branches/release_1_0" and in
(2) it is "trunk".
The real difference between the two approaches you've outlined is where
development happens.
In (1) you might develop your code on a branch, and when its finished
merge it back to somewhere (I'm not sure what you're proposing here - if
I can't merge it back to trunk, where do I merge it to?). Of course I
could also do interim merges to see what other changes have been done.
In (2) you might develop your code on trunk, and when its finished
commit it. Of course you could also do updates whilst developing to see
what other changes have been done.
Obviously there are some details misssing from the development
scenarios, but I think they point out how many similarities there are
between the two options. As with all questions like this, there is
never only one answer - but I think as a general rule if you have a
small(ish), tightly knit development team and do smallish features, (2)
will suit you (this is what we do at work). The bit benefit here is
that its easy to get changes early and often. Of course if you're
having a big feature change that you want to be able to commit whilst
its half done - a branch is a must. If you have a bigger team, or one
in different offices/timezones, then you may find (1) is more suitable.
I do have one question regarding your process - suppose you have the
following scenario. Customer A wants feature X, Customer B wants
feature Y. We currently have version 1.0 on production.
svn://svnserver/product/trunk <- contains 1.0 release
svn://svnserver/product/branches/feature_X <- contains feature X
svn://svnserver/product/branches/feature_Y <- contains feature Y
Both features are complete. Customer A wants feature X, what do you do?
Do you:
a) merge feature_X into trunk and release that (in this case what
happens to customer B, do you tag the release - in which case that is
your prod code, not trunk)
b) merge trunk into feature_X and release that (in this case you have a
production version on a branch, and I don't see what changes there would
be to merge from trunk anyway)
c) do something else?
I just don't see how you can handle even the simplest of scenarios
without being prepared to have multiple branches. If you only have one
customer then this is simplified, but having multiple customers seems to
be central to your argument.
cheers
dim
On 11/8/06, Gundersen, Richard <Richard.Gundersen@london-scottish.com>
wrote:
Hi All
We're having a big debate where I work over whether or not to use the
"release" based branching strategy, or the "feature" based way.
I've always worked with the latter. These are the reasons why:
1) Trunk is always stable. This always mimics exactly what's in
production.
2) I do all new work on a branch (whether it's a small
experimental change or a new release which is essentially a collection
of new features). This to me has the following additional advantages
a. My new changes don't affect the production codebase
b. When the customer who requested change X wants it to go live, I
can merge it in to the trunk (because its own isolated branch), and
release only that change (plus whatever was in trunk originally). I then
commit it, tag it, and hey presto, trunk still mimics production
exactly. With the release based approach, with everyone committing
different changes to the trunk, when a customer wants change X to go
live, I have to tell him that it can go live, but I have to tell another
customer that because I have to release X, his change Y must also go
live too. This situation might never occur with systems that have a
simple release lifecycle, but when you're dealing with large systems
with different sets of customers (especially if they have different
legal requirements, or they are in different countries) I think this is
really important.
The arguments against this approach are often:
1) Merging is hard. I don't like it
a. Well, in my experience with Subversion and CVS, merging is
actually quite easy. I might have a few conflicts to resolve every now
and again, but they are usually pretty easy to iron out, especially if I
keep my branch up to date with the trunk (which might have had some bug
fixes done to it over time)
2) Keeping track of lots of branches is hard.
a. Not really. If I use a good naming convention, a handful of
branches are easy enough to keep track of. It's not as if I'm going to
have hundreds of branches to worry about, in reality
3) We have release branches so you know exactly whats on a
production server
a. So does this approach - whatever is on the trunk is in
production. And, a release branch by definition changes over time (until
it's tagged as final after which there will still be an element of
merging involved to get it in sync with the development branch (trunk in
this case)).
I can see why people would favour the release branch strategy, because
it 'sounds' much simpler, but I think the benefits of the feature based
approach far outweigh the negatives. I expect a lot of people to
disagree with me, but it's a good debate and I'd welcome any comments.
Thanks
Richard
*** 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.
______________________________________________________________________
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.
Received on Mon Nov 13 12:04:06 2006