Re: [HACKERS] Function-manager redesign: second draft (long)

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(at)debis(dot)com (Jan Wieck) #