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

Re: Changes to handling version numbers internally

From: Brook Milligan <brook(at)biology(dot)nmsu(dot)edu>
To: peter_e(at)gmx(dot)net
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Changes to handling version numbers internally
Date: 2000-06-30 15:17:27
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Two issues with the new versioning ideas:

-  The version number would be set in as in VERSION='1.2.3'

-  So, we have to change and autoconf that periodically, instead of just
   having a simple 'version.h' file that we vi?

   It doesn't sound to me like something that *belongs* in, as
   it is not required for any tests that configure requires ...

What about having a single file (e.g., VERSION) somewhere that
contains the relevant information (e.g., it only contains 1.2.3).  Any
Makefiles that need it could cat the value into a make variable and
use it; any C files that need it could include it as appropriate.
Alternatively, though probably not so cleanly in some ways, configure
itself could use the value to define a variable that would be
propagated as needed (probably only and config.h).

Another point:

   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 suggest a numbering sequence that is strictly orderable.  This is
really useful for the versioning of the NetBSD code, because the
location of each version within a largaer sequence is immediately
obvious.  The sequence goes something like:

trunk    -+--> 1.4A ---> 1.4B ---> 1.4C ---> ... -+--> 1.5A ---> 1.5B ---> ...
          |                                       |
          |                                       |
releases  +--> 1.4Alpha ---> 1.4Beta ---> 1.4     +--> 1.5Alpha ---> 1.5Beta ---> 1.5
                                           +--> ... ---> 1.4.1 ---> ...

This may not exactly correspond to the NetBSD scheme, but the general
points should be clear: the main trunk versions are incremented in a
nicely sortable order whenever major interfaces change (corresponding
presumably to our need for initdb), and the branches have a similar
clear ordering.  This seems preferable to using versions like 7.1devel
or 7.1b1 which are less formalized and less sortable.


In response to

pgsql-hackers by date

Next:From: Brook MilliganDate: 2000-06-30 15:21:50
Subject: Re: Installation layout
Previous:From: Brook MilliganDate: 2000-06-30 14:56:26
Subject: Re: config.h (was Re: Misc. consequences of backend memory management changes)

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