Subject | Re: [IBDI] Re: [Firebird-admin] Firebird install for Win32 executable name |
---|---|
Author | Frank Ingermann |
Post date | 2001-07-17T22:35:59Z |
Hi Nando / Doug / Lester / David / ...,
[snipped loads of stuff about naming exe's with their version...]
We have requirements similar to Lester's, (also Europe <g>) and i dont't
really want to jump in here in favour of anyone particularly... *but*:
Renaming a <firebird_version_release_subrelease_something>.exe into
firebird.exe (or ibserver.exe or anything else) after the download
makes much more sense to me than downloading [f|i]bserver.exe (or whatever)
and then (hours, days, months later) having to figure out what version it
is (or what it was when i got it).
in short terms:
- put as much versioning info as you possibly can into the downloadable exe
file names. This includes platform/OS, major release, subrelease(s).
- renaming x_y_z_version_1_2_3.exe into [i|f]bserver.exe is straigthforward,
while *assuming* that your current IB/FB exe is version <x> is - as the
name says - no more than an *assumption* in the first place.
(meaning to say: it's easier to *strip out* versioning info from an exe
name than to adding it in afterwards (examine the exe to find out
about its current version) - no OS tools needed etc. (- having said that,
is there something like "show dll version" on lnx platforms???)
- of course it would be helpful to encode the versioning info in the file's
date/time stamp, but (as Lester e.a. pointed out) some copy op. might change
that time stamp, so it's not truly reliable. Anyone having the appropriate
tools can build a Firebird exe, dates may change, exe sizes may change...,
so imho only version infos in the exe's *filename* are the final clue as
to what version you're really dealing with.
and finally - as Nando said, it doesn't *really* matter how the exe is named,
as long as you (SYSDBA) are aware of how the name came to be.
as said - just my 0.02 <put your favourite currency here> :-)
regards,
fingerman
[snipped loads of stuff about naming exe's with their version...]
We have requirements similar to Lester's, (also Europe <g>) and i dont't
really want to jump in here in favour of anyone particularly... *but*:
Renaming a <firebird_version_release_subrelease_something>.exe into
firebird.exe (or ibserver.exe or anything else) after the download
makes much more sense to me than downloading [f|i]bserver.exe (or whatever)
and then (hours, days, months later) having to figure out what version it
is (or what it was when i got it).
in short terms:
- put as much versioning info as you possibly can into the downloadable exe
file names. This includes platform/OS, major release, subrelease(s).
- renaming x_y_z_version_1_2_3.exe into [i|f]bserver.exe is straigthforward,
while *assuming* that your current IB/FB exe is version <x> is - as the
name says - no more than an *assumption* in the first place.
(meaning to say: it's easier to *strip out* versioning info from an exe
name than to adding it in afterwards (examine the exe to find out
about its current version) - no OS tools needed etc. (- having said that,
is there something like "show dll version" on lnx platforms???)
- of course it would be helpful to encode the versioning info in the file's
date/time stamp, but (as Lester e.a. pointed out) some copy op. might change
that time stamp, so it's not truly reliable. Anyone having the appropriate
tools can build a Firebird exe, dates may change, exe sizes may change...,
so imho only version infos in the exe's *filename* are the final clue as
to what version you're really dealing with.
and finally - as Nando said, it doesn't *really* matter how the exe is named,
as long as you (SYSDBA) are aware of how the name came to be.
as said - just my 0.02 <put your favourite currency here> :-)
regards,
fingerman