Hi,
On 6/29/06, BJ Freeman <
[hidden email]> wrote:
> an example would be lasts nights refactor.
> I would expect it to be first a branch.
> then moved into the truck.
> This would let those of us that are not aware, of up coming changes, at
> least see the changes and make plans on our live sites.
OK, that I understand. It's much clearer than the original question ;)
The practices on when to branch and when to develop in trunk are not
set in stone. Different projects / different organizations have
different conventions.
Most projects / organizations use branches only to maintain (i.e. bug
fix, or in rare cases back-port new features) older releases. Current
development is done in the trunk, not in a branch, except for major
things that may seriously hinder backwards-compatability. This is
more or less the most common approach.
The reasoning behind this approach is that there are basically two
types of users. One is the "I want to be cautious, take less risks,
etc." kind, and they use packaged, labelled, tagged releases. The
other kind is the bleeding-edge user, who always works off the trunk.
That user is responsible for their own risk management, e.g. building
and testing the trunk on their infrastructure / with their
application(s) prior to deploying an unreleased version.
But generally speaker, that type of user doesn't impose the onus on
the development community to work in a branch, only to keep trunk
relatively stable for him or her.
That said, if the OFBiz team wants to use branches / tags more
extensively, there's nothing to stop them. It's up to you to convince
them. But from looking at the current tag structure, it's fairly
standard and common. We do the same in many other projects I'm
involved with (and I wasn't involved in OFBiz in the past, I'm just
observing their SVN repository right now).
Yoav
Locked
