Hi Emerson
For a change that is part of an existing design, yes. But quite often
different sets of users have more demanding requirements at some later
date. For example a different way of doing a calculation, or a new use
case that is specific to them.
Note, also that this issue doesn't relate to 'how' the change is
implemented: it could be a simple if-else e.g.
if (user in role FinanceUsers) {
show these screens (or do this calculation) etc
}
What this issue is concerned with is how that change, whatever it is,
gets developed and released.
-Richard
-----Original Message-----
From: emerson cargnin [mailto:echofloripa.yell@gmail.com]
Sent: Thursday, November 09, 2006 11:46 AM
Cc: subversion-2006d@ryandesign.com; Gundersen, Richard;
users@subversion.tigris.org
Subject: Re: Branching strategy - Feature vs Release
richard
wouldn't this be more a problem of application design? To personalize
this changes dinamically and ve put then in place dinamically thought
configuration?
Emerson
On 09/11/06, Richard Gundersen <richardgundersen@hotmail.com> 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.
>
>
> >From: Ryan Schmidt <subversion-2006d@ryandesign.com>
> >To: "Gundersen, Richard" <Richard.Gundersen@london-scottish.com>
> >CC: <users@subversion.tigris.org>
> >Subject: Re: Branching strategy - Feature vs Release
> >Date: Wed, 8 Nov 2006 17:41:19 -0600
> >
> >
> >On Nov 8, 2006, at 10:12, Gundersen, Richard wrote:
> >
> >>I haven't had anywhere near the number of replies I was expecting
saying
> >>my approach is awful.
> >>
> >>Perhaps this is because it's something that's been debated to death
> >>before and nobody wants to get it started again. Or perhaps it's
because
> >>it really is better than the release-based branching strategy
(trying to
> >>stir up some controversy here :) )
> >>
> >>Does anyone know of any real advantages the release-based approach
has
> >>over the feature-based way?
> >
> >I never imagined that these were conflicting strategies; I think they
can
> >and in many cases should coexist harmoniously. I'm just enjoying
reading
> >your arguments and the responses in this discussion; I don't have
too much
> >to add to it.
> >
> >In the company where I worked, we primarily used release branches;
most
> >changes to be made were small enough that they could be done in one
or two
> >commits, and thereby not destabilize the trunk. However, we did
allow
> >larger development to occur on trunk, even leaving it unstable,
while
> >releases could still be cut from the latest stable release branch.
One of
> >our developers liked the feature-branch idea and used it on some
> >occasions, but the rest of us didn't bother to learn or practice
that.
> >
> >I'm not at all convinced that the way we used Subversion was the best
way,
> >so I'm certainly interested in reading the arguments in this thread.
> >
> >
> >>Anyone know how are Subversion releases themselves done?
> >
> >Looking at the branches directory of the Subversion repository, I
think
> >it's safe to say that they make use of both strategies:
> >
> >http://svn.collab.net/repos/svn/branches/
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> >For additional commands, e-mail: users-help@subversion.tigris.org
> >
>
> _________________________________________________________________
> The new Windows Live Toolbar helps you guard against viruses
> http://toolbar.live.com/?mkt=en-gb
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
______________________________________________________________________
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
Received on Thu Nov 9 12:55:35 2006