Re: Adding optionally commit number in PG_VERSION_STR

Hi all,

It happens that I work occasionally on multiple builds based on
different stable branches at the same time to check fixes that need to
be backpatched, and I tend to easily lose track on which version the
build I created is based on (Duh!). There is of course the version
number up to the 3rd digit available (for example 9.2.4, 9.3beta2,
etc.), but as a developer I think that it would be helpful to include
the commit ID in PG_VERSION_STR to get a better reference on exactly
what the development build is based on. This could be controlled by an
additional flag in ./configure.in called something like
--enable-version-commit, of course disabled by default. If enabled,
PG_VERSION_STR would be generated with the new information. configure
would also return an error when this flag is enabled if git is either
not found, or if the repository where configure is not a native git
repository.

Thoughts?
--
Michael

Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
> It happens that I work occasionally on multiple builds based on
> different stable branches at the same time to check fixes that need to
> be backpatched, and I tend to easily lose track on which version the
> build I created is based on (Duh!). There is of course the version
> number up to the 3rd digit available (for example 9.2.4, 9.3beta2,
> etc.), but as a developer I think that it would be helpful to include
> the commit ID in PG_VERSION_STR to get a better reference on exactly
> what the development build is based on. This could be controlled by an
> additional flag in ./configure.in called something like
> --enable-version-commit, of course disabled by default. If enabled,
> PG_VERSION_STR would be generated with the new information. configure
> would also return an error when this flag is enabled if git is either
> not found, or if the repository where configure is not a native git
> repository.

Personally, I'd find that pretty useless, because the build I'm running
has typically got uncommitted changes in it. Also, there isn't any good
way to set PG_VERSION_STR except at configure time, which means the
common practice of doing (at most) "make clean" before rebuilding would
not result in an updated string even if you had committed.

regards, tom lane

On Wed, July 17, 2013 05:27, Tom Lane wrote:
> Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
>> It happens that I work occasionally on multiple builds based on

FWIW, I've been doing this for while:

where $project is mostly the patchname, $commit_hash is extracted like this:

commit_hash=$( cd /home/aardvark/pg_stuff/git/master; git log | head -n 1 | cut --delimiter=" " -f 2 );

version_string=${project}-${db_timestamp}-${commit_hash};

perl -i.original -ne "
s,(PACKAGE_.*[[:digit:]]+\.[[:digit:]]+(?:\.[[:digit:]]+)?(?:devel)?(?:(?:alpha|beta|rc)[[:digit:]]+)?),\\1-${version_string},;
print;" configure

Which will then give:

PostgreSQL 9.4devel-HEAD-20130717_0828-ffcf654547ef38555203e6d716f47b7065a0a87d on x86_64-unknown-linux-gnu, compiled by
gcc (GCC) 4.8.1, 64-bit

Btw, in an even more ugly hack I also stick some of that same config data in information_schema.sql_packages, with a
feature_id >= 100:

select * from information_schema.sql_packages where cast(substring(feature_id from E'^PKG([[:digit:]]+)') as integer) >= 100
feature_id | feature_name | is_supported | is_verified_by | comments
------------+--------------------+--------------+----------------+----------------------------------------------------------------------
PKG100 | project name | YES | ej | HEAD
PKG101 | patched | NO | ej | NO
PKG103 | build time | YES | ej | 2013-07-17 08:32:03.400521+02
PKG104 | server_version | YES | ej |
9.4devel-HEAD-20130717_0828-ffcf654547ef38555203e6d716f47b7065a0a87d
PKG105 | server_version_num | YES | ej | 90400
PKG106 | port | YES | ej | 6544
PKG110 | commit hash | YES | ej | ffcf654547ef38555203e6d716f47b7065a0a87d
PKG111 | catversion | YES | ej | 201307161
PKG112 | control version | YES | ej | 937
(9 rows)

Needless to say, YMMV ...

Thanks,

Erik Rijkers

On Wed, Jul 17, 2013 at 2:55 AM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> Hi all,
>
> It happens that I work occasionally on multiple builds based on
> different stable branches at the same time to check fixes that need to
> be backpatched, and I tend to easily lose track on which version the
> build I created is based on (Duh!). There is of course the version
> number up to the 3rd digit available (for example 9.2.4, 9.3beta2,
> etc.), but as a developer I think that it would be helpful to include
> the commit ID in PG_VERSION_STR to get a better reference on exactly
> what the development build is based on. This could be controlled by an
> additional flag in ./configure.in called something like
> --enable-version-commit, of course disabled by default. If enabled,
> PG_VERSION_STR would be generated with the new information. configure
> would also return an error when this flag is enabled if git is either
> not found, or if the repository where configure is not a native git
> repository.

FYI, we include the output from "git describe --always" in the pgAdmin
version meta info, which is displayed on the About box along with the
regular version info. That has proven to be extremely useful in the
past, particularly during QA where people may be testing snapshot
builds.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Wed, Jul 17, 2013 at 5:20 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
> On Wed, Jul 17, 2013 at 2:55 AM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
>> Hi all,
>>
>> It happens that I work occasionally on multiple builds based on
>> different stable branches at the same time to check fixes that need to
>> be backpatched, and I tend to easily lose track on which version the
>> build I created is based on (Duh!). There is of course the version
>> number up to the 3rd digit available (for example 9.2.4, 9.3beta2,
>> etc.), but as a developer I think that it would be helpful to include
>> the commit ID in PG_VERSION_STR to get a better reference on exactly
>> what the development build is based on. This could be controlled by an
>> additional flag in ./configure.in called something like
>> --enable-version-commit, of course disabled by default. If enabled,
>> PG_VERSION_STR would be generated with the new information. configure
>> would also return an error when this flag is enabled if git is either
>> not found, or if the repository where configure is not a native git
>> repository.
>
> FYI, we include the output from "git describe --always" in the pgAdmin
> version meta info, which is displayed on the About box along with the
> regular version info. That has proven to be extremely useful in the
> past, particularly during QA where people may be testing snapshot
> builds.
Yes, that's also something tracked for the QA/QE tests at VMware.
Having such an option in core would be a good thing for many people
IMHO instead of using some manual scripting.
--
Michael