Just a short update to tell you all that Mercury/32 v4.51 is now frozen and release is imminent. The test team has had the first release candidate for three days, and the only thing discovered that we felt it was necessary to change was an issue where a new feature in v4.51 conflicts with some utilities written for older versions of the program. In the interests of peace and harmony, I added an option to v4.51 to have it behave like older versions for the benefit of those utilities, and final evaluation is being done on that change now.
All I have remaining to do is the updates to the manual, which I hope to have finished by the end of today. At this point, things look good for a release on either Sunday or Monday my time.
I apologize this has taken such a long time... Those of you who have read my Mercury development blog in the last couple of days will see that I find the process of release quite agonizing, but I believe this should be a good one - no previous version of the program has ever been tested as intensively as this one.
Watch this space for more news.
Cheers!
-- David --
Each time I've prepared a release candidate, some minor issue has come up to prevent me from releasing it.
I thought I was going to be releasing it tonight, but at the very last possible moment one of my test team sent a message that stopped me cold in my tracks.
Read my blog (the one entitled "Everything you never wanted to know about releasing software" and you'll see that release time is the most stressful time in my life these days - the process is so very painful that it takes very little to knock me off my stride.
Assuming the current issue can be resolved, the release is ready to go - the installer archive is finished and has been tested extensively, and it's just a case of uploading it, changing the web pages, and sending out notifications. But I'm not going to do the release until this issue is resolved.
I'm really sorry for the delay - I hate it, but I would hate worse releasing something and getting an avalanche of problem reports. I have to be sure that it's right.
Cheers!
-- David --
Thanks for the update David.
I happy to wait until you're totally happy with the release...
BUT .. I want it ... :)
For what it's worth, what should (I hope) be the final iteration of the release archive has just gone out to the test team for final validation. If they pass it as clean, I'll be releasing it late tonight.
Cheers!
-- David --
just downloaded v4.51:
Quote:
SpamHalter and ClamWall included Lukas Gebauer's proven SpamWall Bayesian Spam Filtering technology has been renamed SpamHalter, and is now included as a standard part of the Mercury distribution, as is his ClamWall anti-virus filter interface. We encourage you to support Lukas with donations at his web site if you use these superb Mercury plugins.
Where do I find them ? I can't see them..
The installer offers to install them for you on a new install, but on an upgrade, you have to do it yourself. You'll find the three installers in the DAEMONS subdirectory of your Mercury install directory.
Cheers!
-- David --
[quote user="tomt"]
Where is the download available from ?
Thanks :)
[/quote]
http://ftp.usm.maine.edu/pegasus/mercury32/m32-451.exe
But perhaps you better wait for the official release via the Mercury and pm-news lists on bama. I'm sure it will be announced here as well.
-- Han van den Bogaerde - support@vandenbogaerde.net Member of Pegasus Mail Support Group. My own Pegasus Mail related web information: http://www.vandenbogaerde.net/pegasusmail/
[quote user="David Harris"]The installer offers to install them for you on a new install, but on an upgrade, you have to do it yourself.[/quote]
A minor point, but I found the same window offering to install them, both on a fresh install and later on an upgrade of 4.01c.
I upgraded last night... Seems to be working well.
Not installed GreyWall or SpamHalter as yet.. GreyWall seems a simple setup, SpamHaulter see a little more intense !
Any reason to use ClamWin over BitDefender ? BitDefender is currently configured as a Policy PreFilter.
Thanks
[quote user="tomt"]Any reason to use ClamWin over BitDefender ? BitDefender is currently configured as a Policy PreFilter.[/quote]
I have used a policy with a command-line scanner and it works well.
Clamav has the advantage of a memory-resident scanner (clamd) that saves the overhead of loading and unloading a separate program, so loading/throughput is better.
If that's not a problem for you and you are happy with your a/v, then there is no need to change. I use Clamav on the server and a different a/v on the workstations (currently F-Prot), just as an extra assurance.
[quote user="PaulW"]
[quote user="David Harris"]The installer offers to install them for you on a new install, but on an upgrade, you have to do it yourself.[/quote]
A minor point, but I found the same window offering to install them, both on a fresh install and later on an upgrade of 4.01c.
[/quote]
I actually pulled the release archive from the server and corrected this, then re-upped it. I'm at a loss to explain how we missed that... The inclusion of Lukas's Daemons is one of the most important features in v4.5, and not having the installer offer to setup them up on upgrades was a pretty glaring oversight.
I'm just finishing the web page updates and announcement messages now - expect to see formal release notifications later today.
Cheers!
-- David --
Your previous draft for topic is pending
If you continue, your previous draft will be discarded.