doh - didn't reply all.
On 11/13/06, Dmitri Colebatch <email@example.com> wrote:
> Hi Richard,
> On 11/13/06, Gundersen, Richard <Richard.Gundersen@london-scottish.com>
> > 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.
> > 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.
> > 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).
Received on Mon Nov 13 12:27:00 2006