> 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
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.