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

Re: Release stamping (Was: [CORE] Schedule for release?)

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>,<pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Release stamping (Was: [CORE] Schedule for release?)
Date: 2006-10-24 20:59:41
Message-ID: 6BCB9D8A16AC4241919521715F4D8BCEA0FCC4@algol.sollentuna.se (view raw or flat)
Thread:
Lists: pgsql-hackers
> >> Sorry - we're just talking about getting the version 
> number in there 
> >> automatically to avoid it getting forgotten during release 
> bundling.
> 
> > I can see that being a good idea. But I don't see Toms ./configure 
> > solution working.
> 
> Why not?  The shipped tarball would contain exactly the same
> pg_config.h.win32 it does today; the only difference is that 
> the version info would've been inserted automatically instead 
> of manually.
> (The start of this discussion was my observation that 
> pg_config.h.win32 contains multiple copies of the version 
> info, and sooner or later somebody would miss one while 
> stamping a release.)

Right. And then you can only build from tarball and not from CVS, right?
Because the pg_config.h.win32 with version is actually in cvs. Or an I
missing something here?


> > What we could do is have the msvc build scripts edit the file and 
> > replace the version with something it reads from 
> configure.in when run.
> 
> That's great if you're using msvc, but what about borland?

Good point. But we could always make that part of the script a separate
one that can be run for Borland as welll.

//Magnus

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2006-10-24 21:05:16
Subject: Re: Release stamping (Was: [CORE] Schedule for release?)
Previous:From: JEAN-PIERRE PELLETIERDate: 2006-10-24 20:45:08
Subject: server process (PID 1188) exited with exit code -1073741819, 8.2 beta1

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