Open Source (was Don't you just wish Rev would do this?)
david at openpartnership.net
Sun Jun 10 03:54:02 CDT 2007
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 <chipp at chipp.com> wrote:
> 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
> 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
> when fixing one bug only to see a ripple effect of it creating many more.
More information about the use-livecode