Richard Gundersen wrote:
> Glad you are enjoying it :)
> I like a good debate and I might be proven wrong. I'm applying my
> previous experience to a new company where we don't have a strategy yet.
> 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.
> 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.
This discussion is very interesting for me as well. We use Subversion
for lots of different products: Internal web development, development
tools, firmware that goes into manufactured hardware, outsourced
software, PC applications, etc. Each of these require different policies
and branching strategies. It boils down to what's best for your process;
it's not that feature branches are better than release branches or
vice-versa. Choose a strategy that works best for your process.
We have some applications that have the same constraints as above;
different countries require different features. We have a 'base'
application that supports the common features. It uses a release-branch
strategy. Each customer or country version then is on its own branch,
which is more like a feature-branching strategy.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Nov 9 15:55:31 2006