On 12/21/06, Lesley Walker lesley.walker@opus.co.nz wrote:
Quanah wrote:
Yeah, my point is that I generally find the "stable" tag misleading, in that the revision often marked "stable" is known to have any variety of issues.
According to the FAQ: | The term "stable" refers to the last "general use" release | that has demonstrated itself as being reliable in real | world environments.
I'm curious. How is that tested, and whose "real world environments" provide the litmus test?
In particular right now, there is a known DoS vulnerability in 2.3.27, which to me means in no way would I even deploy it, since there's an existing exploit.
In your environment that makes a lot of sense. In mine, that would be less of a concern.
The general policy Lesley is using I think is flawed. ;)
The policy is based on comments such as the above quoted from the FAQ. Personally, I feel a little nervous about rolling out a 4-points-old release. My employer feels nervous about rolling out a newer release that hasn't had as much real-world bedding-in time, and I can see his point.
The outcome is that we will continue to go with "stable". We will easily be able to roll back to our current release if there are problems that are immediately evident. But I may well build a later release and have it on hand "just in case".
Thanks for input, everyone.
I think 2.3 was feature-frozen a while ago (2.3.20?), so everything is now bug-fixes. This bit of knowledge might make rolling out the more current version sit better.