my 2cents: makes sense to me.
On Dec 7, 2009, at 2:15 PM, Kalle Korhonen wrote:
I do everything lazily :) - the cost of creating the branch is the
same and it's not clear we ever need to pay that cost, so why pay it
upfront. If we had a roadmap that would dictate the features that go
into 1.1, then sure, we should create the branch as well. Until then,
it's all bug fixes. "Many tags, few branches", that's my motto.
Kalle
On Mon, Dec 7, 2009 at 2:03 PM, Les Hazlewood
<[email protected]> wrote:
Yep, this is exactly what we do at work for all of our releases. It
works quite well.
In practice, we always tag every release and only create a branch if
there are bugs reported against a previous release. If there is no
branch at the time an issue is reported, we create one at that time
off of the tag and then do our bug fixes in this 'lazily-created'
branch.
The only benefit this provides is that the number of branches tends
to
be smaller over time, making it easier to browse the SVN branches
directory. But I certainly have no problems with always creating a
branch no matter what if that's what people prefer. Any preferences?
Les
On Mon, Dec 7, 2009 at 3:40 PM, Kalle Korhonen
<[email protected]> wrote:
On Mon, Dec 7, 2009 at 12:23 PM, Alan D. Cabrera <[email protected]
> wrote:
If one uses a branch name branches/1.x and let's say that 1.0,
1.1, and 1.2
have been released, what do you do when you need to patch 1.1?
When you
When 1.1.0 is released, a 1.1.x branch is created (or it's created
later from 1.1.0 tag when needed). Once we release 1.0.0, we could
either immediately create 1.0.x branch and prepare trunk for 1.1.0
development, or we prepare trunk for 1.0.1 development and branch
the
same way later as needed.
make this 1.x branch what goes into trunk?
If there's a 1.x branch, it implies that trunk has already moved to
2.x (following the release branch pattern - the version "farthest
out"
is in the trunk). The x in the branch name denotes "the trunk for
all
versions of <version>.x"
Kalle
