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/
=====================================================


Reply via email to