Changes to handling version numbers internally - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Changes to handling version numbers internally
Date
Msg-id Pine.LNX.4.21.0006292141070.397-100000@localhost.localdomain
Whole thread Raw
Responses Re: Changes to handling version numbers internally
Re: Changes to handling version numbers internally
Re: Changes to handling version numbers internally
List 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@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Big 7.1 open items
Next
From: Peter Eisentraut
Date:
Subject: Installation layout