Re: [HACKERS] v6.4.3 ?

From: jwieck(at)debis(dot)com (Jan Wieck)
To: maillist(at)candle(dot)pha(dot)pa(dot)us (Bruce Momjian)
Cc: jwieck(at)debis(dot)com, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] v6.4.3 ?
Date: 1999-02-07 21:06:03
Message-ID: m109bP2-000EBPC@orion.SAPserv.Hamburg.dsh.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > Doing it this way means, that a mission critical installation
> > will use v6.4.* until some time after we've put out at least
> > v6.5.1. Thus, we should care about them.
>
> Now I see why you patching against 6.4.

That's the reason. One of the biggest drawbacks against
Postgres is (for many companies at least), that you can't buy
support.

If we only care a little for the last official release
branch, it'll be much better than any payable support for a
commercial product. Yes, I believe it - we have the power.

I recall some replies to recent problem reports on v6.3.2
where we told "upgrade to v6.4.2" (shame on us). That's
easier said than done, if someone has big applications
breaking on new features.

I know that it isn't true, but these "upgrade to another
release" answers instead of "install bugfix release vX.X.X"
look like we don't care about anyone who really uses
Postgres, not only playing around with it just for fun.
That's the sound of M$.

Patching against v6.4 takes time. It must be done manually
nearly all the time since patches don't apply clean. But it's
the only way to give Postgres a real good reputation.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck(at)debis(dot)com (Jan Wieck) #

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 1999-02-07 21:30:00 Re: [HACKERS] v6.4.3 ?
Previous Message Peter T Mount 1999-02-07 21:02:32 RE: [HACKERS] Problems with >2GB tables on Linux 2.0