Thread: 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
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/
Hi! Sounds good, thanks.
--
Deepak
--
Deepak
On Thu, Jan 31, 2013 at 9:11 AM, Magnus Hagander <magnus@hagander.net> wrote:
On Thu, Jan 31, 2013 at 12:20 AM, deepak <deepak.pn@gmail.com> wrote:Thanks, I've applied a change like this (though with the description
> 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?
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/