Re: [HACKERS] Function-manager redesign: second draft (long) - Mailing list pgsql-hackers

From wieck@debis.com (Jan Wieck)
Subject Re: [HACKERS] Function-manager redesign: second draft (long)
Date
Msg-id m11iT17-0003kLC@orion.SAPserv.Hamburg.dsh.de
Whole thread Raw
In response to Re: [HACKERS] Function-manager redesign: second draft (long)  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: [HACKERS] Function-manager redesign: second draft (long)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Peter Eisentraut wrote:

> On Oct 30, Jan Wieck mentioned:
>
> >     Right.   A   major   release  is  what  it  is.  And  porting
> >     applications to a new major release too, it is a  conversion,
> >     not an upgrade. Therefore a major release should drop as much
> >     backward compatibility code for minor releases as possible.
>
> Certainly true. But that would also mean that we'd have to keep
> maintaining the 6.* series as well. At least bug-fixing and releasing one
> or two more 6.5.x versions. Up until now the usual answer to a bug was
> "upgrade to latest version". But if you break compatibility you can't do
> that any more. (Compare to Linux 2.0 vs 2.2) I'm just wondering what the
> plans are in that regard.

    Sometimes  ago, I already pointed out that we have to support
    one or too older releases for some time. Not only because  we
    might  drop  some  compatibility  code.  Each release usually
    declares one  or  the  other  new  keyword,  making  existing
    applications  probably  fail  with  the  new  release. And no
    amount of compatibility code would help in that case! It's  a
    deadlock trap, an application that cannot be easily ported to
    a  newer  release  because  of   incompatibilities   in   the
    querylaguage  cannot use the last release it is compatible to
    because of a bug.

    There is a new aspect in this discussion since then. The  new
    corporation PostgreSQL Inc. offers commercial support for our
    database (look at www.pgsql.com). If they offer support, they
    must  support  older  releases  as  well,  so  they  need  to
    backpatch already.

    Wouldn't it be a good idea if their return into  our  project
    are   bugfix   releases   of   older   versions  (created  by
    backpatching release branches)?  In the case of  a  customers
    accident,  they  have  to  do  it  anyway.  And  doing it for
    critical bugs during idle time could avoid accidents, so it's
    good customer service.

    Marc, what do you think about a such an agreement?


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

pgsql-hackers by date:

Previous
From: Lamar Owen
Date:
Subject: Re: [HACKERS] pgaccess 0.98
Next
From: Mike Mascari
Date:
Subject: Re: [HACKERS] sort on huge table