Version numbers for binaries
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
On Thu, Jan 31, 2013 at 12:20 AM, deepak <deepak.pn@gmail.com> wrote:
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?
Thanks, I've applied a change like this (though with the description
mainly in the commit message and not in a code comment, so not using
your patch) for head and backpatched it into the supported branches,
as it's clearly wrong.
For future reference, please post patches to the pgsql-hackers
mailinglist, instead of the pgsql-general, to make sure that it gets
the attention of the developers. It worked this time, but that's
better for next time.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Hi! Sounds good, thanks.
--
Deepak
On Thu, Jan 31, 2013 at 9:11 AM, Magnus Hagander <magnus@hagander.net>wrote:
Show quoted text
On Thu, Jan 31, 2013 at 12:20 AM, deepak <deepak.pn@gmail.com> wrote:
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?
Thanks, I've applied a change like this (though with the description
mainly in the commit message and not in a code comment, so not using
your patch) for head and backpatched it into the supported branches,
as it's clearly wrong.For future reference, please post patches to the pgsql-hackers
mailinglist, instead of the pgsql-general, to make sure that it gets
the attention of the developers. It worked this time, but that's
better for next time.--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/