Upgrading Minor versions

Glenn Steen glenn.steen at gmail.com
Fri Aug 3 08:49:02 IST 2007


On 03/08/07, Res <res at ausics.net> wrote:
> Hi Kai,
>
> On Fri, 3 Aug 2007, Kai Schaetzl wrote:
>
> > Eugene MacDougal wrote on Thu, 2 Aug 2007 16:27:50 -0500:
> >
> >> Is there some way to make the installer check to see if its about to overwrite files?
> >
> > Eugene, it normally doesn't overwrite existing config files, not on major, not on minor
> > version changes. Can you provide more details?
>
> Yes, on source versions, its happened to me before, thankfully its
> all under /opt and backed up nightly anyway, even on dummy test machines
> :)
>
> This is why I mentioned a couple of days ago about bringing it into line
> with most other software versioning,  major.minor.beta_number as in
> 4.63.b1, 4.63.b2 etc reaching the official release as 4.63 (as only 4.63)
> major. MailScanners installer does not understand at all 4.63.3-5 only
> 4.63.3, thereby over-writting. As Julian ignored my comments I dare say he
> has no intention of changing it, as no one else commented, it seems most
> are happy with it, and I also gather after years of observations 95% of
> people here use RPM base OS's so they may not be affected by the
> installers tarball shortfall.
>
In the RPM case the -<number> isn't really part of the packaged
software version number... it is more considered to be a package
revision number. Indeed, RPM (and other packagers) will take note of
that difference and act accordingly/safely.
So perhaps it is the "tarball install method" that need be amended,
more than the actual numbering scheme... Or one could make it a
documentation thing... Prominently (on the download page) warn to make
a cakcup of the /opt/MailScanner<.whatever> directory prior to
unpacking/installing the tarball.

Cheers
-- 
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se


More information about the MailScanner mailing list