RE: Re: Branching strategy - Feature vs Release

        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

Wow - was I really that balanced? Completely unlike me (o:

I'm favouring the approach you described as release branching.

>>>>>>>>>>>>>

            bah! ;)

>>>>>>>>>>>>>

        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.

Not unless you deploy it to production it doesn't. And if you deploy it
to production then you can no longer have feature Y without feature X,
unless you do a reverse merge of feature X and then merg in feature Y
and re-release. Seems like an aweful lot of trouble for something that
I've never encountered a request for. Maybe I just haven't worked in
the sorts of environments where I get those requests.

>>>>>>>>>>>>>>>>>>>>>

                        The idea is that you commit the merged changes
once they have been released. You can treat the commit as a step in the
release process. If you only merged & released feature X, and you
committing that merge, the trunk certainly does reflect production. You
could do X and Y at the same time if you like, with the same result. The
difference is, you have a CHOICE.

The feature strategy makes things easier, not harder. The only mental
hurdle you have to overcome is that you WILL do some branching and
merging from the start. But, using the release strategy, you'll be doing
it anyway - just in a different direction, and probably later.

>>>>>>>>>>>>>>>>>>>>>

        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!)

I don't understand what you're saying here. If they are all running the
same version, then how would you ever release one feature to one
customer only. That to me implies that you are releasing multiple
copies of the code (or at least multiple branches).

>>>>>>>>>>>>>>>>>>>>>

                        Customer A might come along and request a new
way of doing a certain calculation but only for them. They might want a
whole new use case that other users don't have access to. The list is
endless. I've worked on some systems used by different users in 20
different countries. Believe me, they do make these kinds of request.
And it's their system, they always get their changes ;)

>>>>>>>>>>>>>>>>>>>>>

cheers,

dim

______________________________________________________________________
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:43:20 2006