Thread: 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.paquier@gmail.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.paquier@gmail.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)
>=100feature_id | feature_name | is_supported | is_verified_by | comments
------------+--------------------+--------------+----------------+----------------------------------------------------------------------PKG100
| project name | YES | ej | HEADPKG101 | patched | NO | ej
| NOPKG103 | build time | YES | ej | 2013-07-17 08:32:03.400521+02PKG104 |
server_version | YES | ej |
9.4devel-HEAD-20130717_0828-ffcf654547ef38555203e6d716f47b7065a0a87dPKG105 | server_version_num | YES | ej
| 90400PKG106 | port | YES | ej | 6544PKG110 | commit hash
|YES | ej | ffcf654547ef38555203e6d716f47b7065a0a87dPKG111 | catversion | YES
|ej | 201307161PKG112 | 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.paquier@gmail.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@pgadmin.org> wrote: > On Wed, Jul 17, 2013 at 2:55 AM, Michael Paquier > <michael.paquier@gmail.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