But it would feel equally silly if we went with the latest release and encountered a new bug that appeared since the "stable" release that just happened to be triggered by something that turned out to be weird in our environment and nobody else noticed it before. :-)

Quanah Gibson-Mount wrote: > > So, why not just run the latest one? ;) As Lesley wrote in his first e-mail: Since we are utterly dependant on OpenLDAP for many things, policy is to go with "stable". At the moment in the 2.3 release branch the stable tag should IMO be officially forwarded to the last releases. It's way behind the current recommendations on the list. IMO the current situation is confusing for deployers.

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.