On Jan 30, 2009, at 11:05 PM, Chris Frey wrote:
> What are your thoughts on managing miscellaneous patches for upcoming
> releases?
Patches appear on the mailing list or are attached to the gna.org bug
DB. There they wait until I get around to starting v4. This is how I
handled v3, and that worked out all right.
> Is the lack of future branches due to it being a pain
> to manage, or just the lack of such patches coming in?
The virtue of branches is that they allow simultaneous development of
divergent variants of a single project, with easier re-synchronization
than if you don't use branches. Not easy, just easier.
The occasional contributed patch, while much appreciated, doesn't
count as simultaneous development. The minimum it'd take to qualify
is a second person working on MySQL++ about as much as I do now, but
on a different version. Unless you're wanting to start v4 now, Chris,
with an eye to getting it out within the six months, I don't see the
justification for a branch. And if you were thinking of starting on
v4, I'd ask why not help me get 3.1 out the door instead, so we can
both get to v4 faster?
If there's only one person putting in 90%+ of the development and
maintenance effort, as now, all branches do is force that person to do
periodic merging, to keep the branches in synch. That's a far greater
cost than has to be paid to integrate a 2-year old patch into a new
release. (Speaking from v3 experience again.) It doesn't take much
pain per branch synchronization to match the one-time pain of forward-
porting a patch when that merge pain is repeated frequently over the
course of years.
In short, I'm refusing to use the hammer because I perceive that the
things in front of me are not nails.
