Changes to handling version numbers internally

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Changes to handling version numbers internally
Date: 2000-06-29 23:34:08
Message-ID: Pine.LNX.4.21.0006292141070.397-100000@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I'd like to change some things about how the code handles the information
about its own version number.

The version number would be set in configure.in as in

VERSION='1.2.3'

(Keep it in configure.in because it would be nice to have this information
available globally. One fine day we might even automatically make tarballs
with this.)

config.h defines the symbol PG_VERSION (VERSION is probably too prone to
clashes) as "1.2.3", which applications can then use to display --version
information of whatever.

The canonical string "PostgreSQL x.y.z compiled by zz" is still available.

Applications that want to test for "release compatibility" like 7.0.1 vs
7.0.2 can use strtod(PG_VERSION, NULL) and then use a simple `==' or `<',
etc. (Of course you're free to parse yourself "number"-"dot"-"number".
That's not hard.)

Right now I think we should set it to '7.1devel', later to '7.1b1',
etc. It's really quite wrong to label it '7.1' already now.

I also think that we could scrap the pg_version program. Its function is
to create a file PG_VERSION in the directory given as argument, and it's
called by initdb. Why not just substitute the version number into initdb
at build time and just `echo > PG_VERSION'? One less level of redirection.

--
Peter Eisentraut Sernanders väg 10:115
peter_e(at)gmx(dot)net 75262 Uppsala
http://yi.org/peter-e/ Sweden

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2000-06-29 23:37:49 Re: Misc. consequences of backend memory management changes
Previous Message Peter Eisentraut 2000-06-29 23:34:02 Installation layout