Thread: Changes to handling version numbers internally

Changes to handling version numbers internally

From
Peter Eisentraut
Date:
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



Re: Changes to handling version numbers internally

From
The Hermit Hacker
Date:
On Fri, 30 Jun 2000, Peter Eisentraut wrote:

> 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.)

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 configure.in, as
it is not required for any tests that configure requires ...





Re: Changes to handling version numbers internally

From
Tom Lane
Date:
Peter Eisentraut <peter_e@gmx.net> writes:
> The version number would be set in configure.in as in

Makes sense to me.  Right now there is a list someplace of all the
places that have to be edited to update the version number :-(.
If configure could help centralize/automate that, it'd be great.

I also concur that supporting non-numeric suffixes on the version
string would be a big improvement.

> I also think that we could scrap the pg_version program.

Yes, it seems like dead weight to me too.  I think that it
predates our use of configure, so at the time it might have
been necessary mechanism, but now...
        regards, tom lane


Re: Changes to handling version numbers internally

From
Brook Milligan
Date:
Two issues with the new versioning ideas:

-  The version number would be set in configure.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 configure.in, as  it is not required for any tests that
configurerequires ...
 

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 Makefile.global 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'
alreadynow.
 

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.

Cheers,
Brook


Re: Changes to handling version numbers internally

From
Peter Eisentraut
Date:
The Hermit Hacker writes:

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

This way we can also make it available to shell scripts and make
files. The next autoconf version will have built-in support for this
setup, so it's not like I'm making this up. :)

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




Re: Changes to handling version numbers internally

From
The Hermit Hacker
Date:
On Sat, 1 Jul 2000, Peter Eisentraut wrote:

> The Hermit Hacker writes:
> 
> > It doesn't sound to me like something that *belongs* in configure.in,
> > as it is not required for any tests that configure requires ...
> 
> This way we can also make it available to shell scripts and make
> files. The next autoconf version will have built-in support for this
> setup, so it's not like I'm making this up. :)

I see you've already committed the changes, which I still disagree with
... I don't like the fact that someone has to remember to update the
configure.in and autoconf it to change the version number.  We already
have the mess with template files, why not create a VERSION file that
could just as easily be read in by configure, without having to do an
autoconf, to change the version?





Re: Changes to handling version numbers internally

From
Tom Lane
Date:
The Hermit Hacker <scrappy@hub.org> writes:
>> This way we can also make it available to shell scripts and make
>> files. The next autoconf version will have built-in support for this
>> setup, so it's not like I'm making this up. :)

> I see you've already committed the changes, which I still disagree with
> ... I don't like the fact that someone has to remember to update the
> configure.in and autoconf it to change the version number.

It's a lot better than it was before ;-)

> We already have the mess with template files, why not create a VERSION
> file that could just as easily be read in by configure, without having
> to do an autoconf, to change the version?

Gilding the lily.  The people who are likely to be bumping the version
number are all perfectly familar with autoconf.  Also, we've already
got bad-enough problems with dependencies (see nearby thread) without
introducing a dependency from a file that's read by configure to
who-knows-where --- a dependency that can't be handled by 'make depend'.
        regards, tom lane


Re: Changes to handling version numbers internally

From
The Hermit Hacker
Date:
On Sun, 2 Jul 2000, Tom Lane wrote:

> The Hermit Hacker <scrappy@hub.org> writes:
> >> This way we can also make it available to shell scripts and make
> >> files. The next autoconf version will have built-in support for this
> >> setup, so it's not like I'm making this up. :)
> 
> > I see you've already committed the changes, which I still disagree with
> > ... I don't like the fact that someone has to remember to update the
> > configure.in and autoconf it to change the version number.
> 
> It's a lot better than it was before ;-)
> 
> > We already have the mess with template files, why not create a VERSION
> > file that could just as easily be read in by configure, without having
> > to do an autoconf, to change the version?
> 
> Gilding the lily.  The people who are likely to be bumping the version
> number are all perfectly familar with autoconf.  

Ya, I've been fighting myself internally on this point ... I just hate the
though of embed'ng it into configure, that's all ...

peter mentioned something about next version of autoconf doing this?  



Re: Changes to handling version numbers internally

From
The Hermit Hacker
Date:
On Mon, 3 Jul 2000 eisentrp@csis.gvsu.edu wrote:

> On Sun, 2 Jul 2000, The Hermit Hacker wrote:
> 
> > peter mentioned something about next version of autoconf doing this?  
> 
> Yeah, you write AC_INIT(Package, Version) and that creates the VERSION
> variable and substitutes it, just like I did. (It also creates the PACKAGE
> variable, in case you ever want to rename the package. :)
> 
> If you don't like it in configure.in, I understand, but it seems like that
> would be just one more file to find.

To me, it just seems that it will more often be forgotten then putting it
into a VERSION text file ... but it isn't something that I'm going to turn
blue in face over ... since its as 'clean' as above, leave it ... 

One thought, and with all your recent changes you may have done this, but
is there any way of putting some sort of text file as part of the install
procedure that "stores" the ./configure command line?  Something that, if
I were to remove all sources but decide later that I want to add, let's
say, multi-byte, I could do 'cat ~pgsql/CONFIGURE' to find out how the
system is already compiled? 




Re: Changes to handling version numbers internally

From
eisentrp@csis.gvsu.edu
Date:
On Sun, 2 Jul 2000, The Hermit Hacker wrote:

> peter mentioned something about next version of autoconf doing this?  

Yeah, you write AC_INIT(Package, Version) and that creates the VERSION
variable and substitutes it, just like I did. (It also creates the PACKAGE
variable, in case you ever want to rename the package. :)

If you don't like it in configure.in, I understand, but it seems like that
would be just one more file to find.

-- 
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden



Re: Changes to handling version numbers internally

From
Tom Lane
Date:
The Hermit Hacker <scrappy@hub.org> writes:
> One thought, and with all your recent changes you may have done this, but
> is there any way of putting some sort of text file as part of the install
> procedure that "stores" the ./configure command line?  Something that, if
> I were to remove all sources but decide later that I want to add, let's
> say, multi-byte, I could do 'cat ~pgsql/CONFIGURE' to find out how the
> system is already compiled? 

config.status has always done this.
        regards, tom lane


Re: Changes to handling version numbers internally

From
Peter Eisentraut
Date:
The Hermit Hacker writes:

> One thought, and with all your recent changes you may have done this, but
> is there any way of putting some sort of text file as part of the install
> procedure that "stores" the ./configure command line?  Something that, if
> I were to remove all sources but decide later that I want to add, let's
> say, multi-byte, I could do 'cat ~pgsql/CONFIGURE' to find out how the
> system is already compiled? 

config.status stores the current configuration. To reuse it, run
`./config.status --recheck'. If you just want to *know* what the current
configuration is, then `head config.status' should answer that pretty
well.

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



Re: Changes to handling version numbers internally

From
Tom Lane
Date:
The Hermit Hacker <scrappy@hub.org> writes:
> you guys missed the key part of my message "if I were to remove all
> sources but decide later ..." :)  if I remove sources, I no longer have
> config-status to work with :)

No, I didn't miss it.  IMHO "make distclean" should remove every file
created by configure --- that would include any specialized "CONFIGURE"
output file you might want it to create.  So there's no advantage to
having that over the existing config.status output file.

If you don't want to lose the configure outputs then do "make clean",
not "make distclean".
        regards, tom lane


Re: Changes to handling version numbers internally

From
Peter Eisentraut
Date:
The Hermit Hacker writes:

> you guys missed the key part of my message "if I were to remove all
> sources but decide later ..." :)  if I remove sources, I no longer have
> config-status to work with :)

Well, if you remove everything, then where is that configure command line
saving file going to survive?


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



Re: Changes to handling version numbers internally

From
The Hermit Hacker
Date:
On Thu, 6 Jul 2000, Peter Eisentraut wrote:

> The Hermit Hacker writes:
> 
> > you guys missed the key part of my message "if I were to remove all
> > sources but decide later ..." :)  if I remove sources, I no longer have
> > config-status to work with :)
> 
> Well, if you remove everything, then where is that configure command line
> saving file going to survive?

that is what I'm kinda asking for ... maybe some POSTGRES/etc directory
can be created, or create a file under lib that just contains that one
command?

think about Lamar's RPMs ... might not be many that would, but some might
like to be able to look at a file and see what args he used to configure
it, in case they want to keep what is currently there, but add an option
that he didn't put in ...



Re: Changes to handling version numbers internally

From
The Hermit Hacker
Date:
you guys missed the key part of my message "if I were to remove all
sources but decide later ..." :)  if I remove sources, I no longer have
config-status to work with :)

On Wed, 5 Jul 2000, Peter Eisentraut wrote:

> The Hermit Hacker writes:
> 
> > One thought, and with all your recent changes you may have done this, but
> > is there any way of putting some sort of text file as part of the install
> > procedure that "stores" the ./configure command line?  Something that, if
> > I were to remove all sources but decide later that I want to add, let's
> > say, multi-byte, I could do 'cat ~pgsql/CONFIGURE' to find out how the
> > system is already compiled? 
> 
> config.status stores the current configuration. To reuse it, run
> `./config.status --recheck'. If you just want to *know* what the current
> configuration is, then `head config.status' should answer that pretty
> well.
> 
> -- 
> Peter Eisentraut                  Sernanders v�g 10:115
> peter_e@gmx.net                   75262 Uppsala
> http://yi.org/peter-e/            Sweden
> 

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 



Re: Changes to handling version numbers internally

From
Peter Eisentraut
Date:
The Hermit Hacker writes:

> that is what I'm kinda asking for ... maybe some POSTGRES/etc directory
> can be created, or create a file under lib that just contains that one
> command?
> 
> think about Lamar's RPMs ... might not be many that would, but some might
> like to be able to look at a file and see what args he used to configure
> it, in case they want to keep what is currently there, but add an option
> that he didn't put in ...

Good point. (Although the RPMs do way too much custom patching right now
for this to be very useful.)

Someone recently asked for a utility along the lines of gnome-config so
they can get the installation paths for the libraries and include files
for their package. Maybe we can work the configure command line into that.

$ pg-config --includedir
/usr/local/pgsql/include
$ pg-config --libdir
/usr/local/pgsql/lib
$ pg-config --configure
--enable-debug --with-CXX

Comments?


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



Re: Changes to handling version numbers internally

From
Tom Lane
Date:
Peter Eisentraut <peter_e@gmx.net> writes:
> Someone recently asked for a utility along the lines of gnome-config so
> they can get the installation paths for the libraries and include files
> for their package. Maybe we can work the configure command line into that.

> $ pg-config --includedir
> /usr/local/pgsql/include
> $ pg-config --libdir
> /usr/local/pgsql/lib
> $ pg-config --configure
> --enable-debug --with-CXX

> Comments?

I like it.  We can still say that make distclean wipes the source tree
clean of configure output ... but the install tree retains documentation
about how it was built.

Aside from configure options, it'd at least be important to save the
selected OS template name.  Not sure what else.
        regards, tom lane


Re: Changes to handling version numbers internally

From
The Hermit Hacker
Date:
On Sat, 8 Jul 2000, Peter Eisentraut wrote:

> The Hermit Hacker writes:
> 
> > that is what I'm kinda asking for ... maybe some POSTGRES/etc directory
> > can be created, or create a file under lib that just contains that one
> > command?
> > 
> > think about Lamar's RPMs ... might not be many that would, but some might
> > like to be able to look at a file and see what args he used to configure
> > it, in case they want to keep what is currently there, but add an option
> > that he didn't put in ...
> 
> Good point. (Although the RPMs do way too much custom patching right now
> for this to be very useful.)
> 
> Someone recently asked for a utility along the lines of gnome-config so
> they can get the installation paths for the libraries and include files
> for their package. Maybe we can work the configure command line into that.
> 
> $ pg-config --includedir
> /usr/local/pgsql/include
> $ pg-config --libdir
> /usr/local/pgsql/lib
> $ pg-config --configure
> --enable-debug --with-CXX
> 
> Comments?

That would be perfect also