Marc G. Fournier wrote:
> when we do up Release 7, which I'd like to make this one, I'd *love* to
> make this a whole-hog thing...tag/branch things as REL_7, no minor
> number...then its up to the developers to decide whether something is
> back-patchable (like they've been doing up until now) with a periodic
> release put out while Release 8 is being worked on.
I would really appreceate that. Maybe we need to go ahead in
this manner and make more use of CVS branching.
We have long standing TODO items, which require co work of
multiple developers, affect alot of the code and will take a
long time to implement. Tuple split, fmgr redesign, parsetree
overhaul to name some.
Especially the fact that noone can do them alone IMHO
requires to have a separate branch, where the sources can
stay broken for some time. For example if we change the
parsetree representation, we first change the parser and look
at the printed output's until it fits. Then work on the
planner to get them running and parallel enhance the rewriter
to integrate it again. During this time, the parser will
generate things that may make the entire system unusable, so
any other development would get stuck.
I don't think that all problems could be tackled at once. My
idea is to analyze one of these problems in depth, then
branch off and have the developers, required to get this item
done, doing it separated there. The final result will be a
patch based on an older release, that requires some manual
work to get it merged into the current tree, of course. The
benefit would be, that this long term development would not
be interfered by CURRENT improvements, nor will it delay any
subsequent releasing of funny, neat things.
Just an idea.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #