Re: [HACKERS] 6.6 release

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) #