Discussion:
Version numbers for binaries
(too old to reply)
deepak
2013-01-30 23:20:12 UTC
Permalink
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
Magnus Hagander
2013-01-31 14:11:01 UTC
Permalink
Post by deepak
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-***@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
deepak
2013-01-31 15:21:58 UTC
Permalink
Hi! Sounds good, thanks.


--
Deepak
Post by Magnus Hagander
Post by deepak
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
Post by deepak
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/
Loading...