RE: [Declude.JunkMail] Manual

[Colbeck, Andrew]

Title: Message

I'm all in favour of the manual being sync'ed with the releases.  That's a no-brainer.   Beta support handling is a bone of contention, and I'd rather that support maintenance of those features not interfere with the stellar support we already get from Declude.   Therefore, I suggest that:   1) Create a new mailing list for Declude.JunkMail.Beta that those who live on the bleeding edge can join.  Cross-posting to Declude.JunkMail and Declude.Virus is discouraged.  Announcements of features would be done there.   2) As suggested already, simple documentation of new features under testing be provided, e.g. sample usage and obvious gotchas, rather than the support/beta list getting clogged with people discovering a beta feature and asking how to use it.   3) Tracking what's in the Release and what's in the Beta then makes it irrelevant what's in a given Interim.  Declude could then e-mail out a "new release announcement" to the customer base (that'd be us).  A lot of traffic in this support list is based on administrators who are quite far behind but are seeing "new" tests discussed and want to get up to speed.   4) Perhaps: prefix the Beta feature names with BETA, e.g. BETAHIDETESTS, BETASPFPASS; the onus is then on we the mail administrators to do search and replace when we implement the Release version...?  Valuable or pointless?  Strict or customer-abusive?  Judging by the discussion today, some would prefer the clarity... but then, I only deal with one global.cfg and one $default$.junkmail so my judgement is limited.   Andrew. -----Original Message----- From: Matt [mailto:[EMAIL PROTECTED] Sent: Friday, January 23, 2004 1:34 PM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] Manual Maybe beta's should be by invitation/request only, and distributed only to that group like a normal beta program?  At the same time, bug fixes can be applied to the last release, as well as the most recent beta, or only to the beta's if that's all that is affected?  It's a bit more work to maintain two different sets of code in this way, but it keeps the bugs relating to full releases from requiring you to upgrade to a beta interim release.  This would also cut down dramatically on the overhead of releasing betas to the general public and having to deal with the potential pitfalls of this (i.e. too much discussion). Matt paul wrote: I'll add my .02 worth to this discussion:   What I feel would be the best as a user:   1: Maybe instead of 1.76 beta to 1.77 beta, it should've been 1.76 Release, with an update to the manual about the new features of 1.76.   2: Betas should have a page devoted to the new features with a disclaimer "These may not be in the next release - use at your own risk" That way, those that don't use the betas and wait for an actual release get what they want, and beta users get what they want as well.   Paul -- ===================================================== MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ =====================================================