From: | deepak <deepak(dot)pn(at)gmail(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Version numbers for binaries |
Date: | 2013-01-30 23:20:12 |
Message-ID: | CAALYutdHaDRTmkjpou1jMtqG5kHPkEPsAq5ffxoxv9h_cpbE0Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi !
We bundle Postgres into a Windows MSI, Postgres built with VS2008.
One of the issues we ran into recently is Windows getting confused with the
file
versions of Postgres binaries, confused meaning, it was treating newer
binaries
as older, and hence skipping copying certain files during an upgrade.
Looking further, I came across the file where version numbers for some of
the
binaries are generated (including pg_ctl.exe), and it used to use 2 digit
year
followed by day of year, without any padding. We need to pad the day of
year
with leading zeros to make the version non-decreasing.
I've included a patch below, could this be patched into Postgres?
Index: src/tools/msvc/Project.pm
===================================================================
--- src/tools/msvc/Project.pm (revision x)
+++ src/tools/msvc/Project.pm (revision y)
@@ -306,7 +306,7 @@
my ($self, $dir, $desc, $ico) = @_;
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) =
localtime(time);
- my $d = ($year - 100) . "$yday";
+
+ # Padding with leading zeros makes the version numbers increase over
time.
+ # This helps in preventing dependent programs such as Windows
Installer
+ # from getting confused with lower but newer version numbers.
+ # e.g. version corresponding to 2012/11/27 will be 12331, and the one
+ # for 2013/01/28 will be 1328 without padding, and padding makes it
13028
+ # which is greater than 12331 which will be expected since it is from a
+ # later date.
+ my $d = sprintf("%02d%03d", ($year - 100), $yday);
if (Solution::IsNewer("$dir\\win32ver.rc",'src\port\win32ver.rc'))
{
--
Deepak
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2013-01-30 23:38:26 | Re: naming of wal-archives |
Previous Message | Adrian Klaver | 2013-01-30 23:13:36 | Re: naming of wal-archives |