Skip site navigation (1) Skip section navigation (2)

Re: 7.0 vs. 7.1 (was: latest version?)

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
Cc: Trond Eivind Glomsrød <teg(at)redhat(dot)com>, The Hermit Hacker <scrappy(at)hub(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: 7.0 vs. 7.1 (was: latest version?)
Date: 2000-10-27 04:55:17
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-hackerspgsql-ports
[ Blind CC to general added for comment below.]

> [Taken off GENERAL, added HACKERS to cc:]
> Bruce Momjian wrote:
> > > He's meaning the libpq version for dynamic link loading.  Is the
> > > lib changing versions (like the change from 6.5.x to 7.0.x
> > > changed from to, which broke binary RPM
> > > compatibility for other RPM's linked against, which failed
> > > when came on the scene).  I think the answer is no, but I
> > > haven't checked the details yet.
> > I usually up the .so version numbers before entering beta.  That way,
> > they get marked as newer than older versions.
> May I ask: is it necessary?  Have there been version-bumping changes to
> libpq since 7.0.x? (With the rate that necessary improvement is
> happening to PostgreSQL, probably).

No, only major releases have bumps.

> But, enough rant.  That _is_ I believe what Trond was asking about.  We
> have been bitten before with people installing the PHP from RedHat 6.2
> after installing the PostgreSQL 7.0.x RPMset -- and dependency failures
> wreaked havoc.
> So, PostgreSQL 7.1 is slated to be, then?
> Actually, Bruce, it would do me and Trond a great favor if a list of
> what so's are getting bumped and to what version were to be posted.  At
> least we can plan for a transition at that point.  

See pgsql/src/tools/RELEASE_CHANGES.  I edit interfaces/*/Makefile and
increase the minor number for every interface by one.

Let me add one thing on this RPM issue.  There has been a lot of talk
recently about RPM's, and what they should do, and what they don't do,
and who should be blamed.  Unfortunately, much of the discussion has
been very unproductive and more like 'venting'.

I really don't appreciate people 'venting' on these lists, especially
since we have _nothing_ to do with RPM's.  All we do is make the
PostgreSQL software.

If people want to discuss RPM's on the ports list, or want to create a
new list just about RPM's, that's OK, but venting is bad, and venting on
a list that has nothing to do with RPM's is even worse.

What would be good is for someone to constructively make a posting about
the known problems, and come up with acceptible solutions.  Asking us to
fix it really isn't going to help because we don't deal with RPM's here,
and we don't have enough free time to make significant changes to meet
the needs of RPM's.

Also, remember we support many Unix platforms, and Linux is only one of

  Bruce Momjian                        |
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

In response to


pgsql-ports by date

Next:From: Tom LaneDate: 2000-10-27 14:54:27
Subject: Re: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)
Previous:From: Lamar OwenDate: 2000-10-27 03:48:56
Subject: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)

pgsql-hackers by date

Next:From: Michael TeterDate: 2000-10-27 05:01:41
Subject: renaming columns... danger?
Previous:From: Tom LaneDate: 2000-10-27 04:34:18
Subject: Re: pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c)

pgsql-general by date

Next:From: Bruce MomjianDate: 2000-10-27 04:57:10
Subject: Re: Issues about postgresql file names
Previous:From: Jason EarlDate: 2000-10-27 04:43:11
Subject: Re: binary data and TEXT

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group