Chipp - would it not be the best for "stability" to have the existing release cyle as "stable", and those wishing to live on the bleeding edge (and get faster bug fixes and to participate in experimental features) to opt in for the sort of release cycle that others are requesting?
This is what I usually do for most of the web based doe I use, those projects that I want stable and basic features i download and install, those requiring the latest features that may not be full tested I download with subversion and update much more often. I'd go for the same model with Rev - though the exact method is up for grabs the principle is clear and standard. It's really just making the beta programme more visible (ie its a plugin and an actively discussed option). I for one have only ever heard of beta testing once or twice as an aside on this list. Stability is usually achieved by getting as much and as early user testing as possible. I'd open things up a bit, with a clear disclaimer, and a plugin along the lines of that being discussed. On 10/06/07, Chipp Walters <[EMAIL PROTECTED]> wrote:
Bob, Updating Rev each time a bug fix is made, could be a dicey proposition, as typcially after a bug is fixed, there still should be unit testing, then more inside testing, then beta testing, then rc testing, etc. to make sure fixing the bug didn't break other stuff. I think Rev has taken the position to do all this in the same cycle, which for a company with limited resources, is a good way (IMO) to go. The existing architecture of course could do just as you suggest. But my biggest fear with a system like this would be we would never end up with a fairly stable release. The complexity of Rev could create unforseen problems when fixing one bug only to see a ripple effect of it creating many more.
_______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
