Clay, > Given the number of pre-releases, do you have any rough idea concerning > the 2.7.0 stable release? I have a few boxes in need of an update to > 2.6.4, but may hold until 2.7.0 depending on release timing. > Any thoughts?
The main reason that 2.7.0-pre12 is not named 2.7.0-rc1 is that I would still like to provide a cleaner and more general purpose API/syntax of incorporating SQL and LDAP lookups directly and explicitly into @*_maps lists of lookup tables, instead of the current implicit inclusion of SQL and LDAP into each @*_maps list. Also the amavisd-signer would need a cleaner way of being supplied with its configuration, and preferably supporting a PKCS11 API to access crypto devices for DKIM-signing mail (which I have half-finished) - although this could perhaps wait for the 2.7.1. Both of these might require some less-then-perfect incompatible measure, which would be less appropriate for some later minor-version update - the 2.7.0 would be a perfect corner stone to complete this transition. Whatever changes are happening lately between -pre* releases are some new features for which I have an immediate need or for which I see a good opportunity, or some optimizations, cleaning and some minor bug fixes. As far as functional stability and bug-free operation is concerned, I'd say that 2.7.0-pre12 is as good (if not better) that 2.6.4. So if one does not mind dealing with a potential compatibility change (to implement the first item above) which might still be pending, there is no reason not to go for 2.7.0-pre12, especially with new installations or with major upgrades/overhaul of the whole mail system. The compatibility concerns are clearly documented in release notes, the most intrusive of which is perhaps a need for a couple of new fields in an SQL database if using it (penpals & SQL logging) and possibly a change in data types of some SQL fields. Mark ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ AMaViS-user mailing list AMaViS-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amavis-user Please visit http://www.ijs.si/software/amavisd/ regularly For administrativa requests please send email to rainer at openantivirus dot org
