In the past, Lucene has always pushed patches, but I know I've argued
for branches too. Either way, you end up doing work to merge.
Personally, I feel so comfortable with patches these days that I
rarely think of branching, but that isn't to say it is wrong or that
someone else prefers that way. While I like to keep trunk working,
etc. no one says it has to be perfect, so if you feel something is
ready to commit, then do so. You're more likely to get more eyeballs
on trunk than on a branch, I think, and as long as it is worked out by
the next release, I don't know if it matters.
On Jul 28, 2009, at 6:15 PM, Ted Dunning wrote:
Grant is the process meister here, but what you say is close.
On Tue, Jul 28, 2009 at 2:03 PM, Sean Owen <[email protected]> wrote:
I'm into that. What's the ideal relation between branches and
releases? So I put this in a branch, work on it for a bit, then
re-integrate before 0.2? I don't want to be disruptive but also want
to take advantage of the flexibility we have in the early stages of
the project to push big change into the main branch quickly.
On Tue, Jul 28, 2009 at 9:41 PM, Ted Dunning<[email protected]>
wrote:
Should this be a branch?
--
Ted Dunning, CTO
DeepDyve
