Thomas Mueller <[EMAIL PROTECTED]> said: > "Release early, release often".
Add to that "maintain compatibility along your production branches" > The dynamic preforking patch seems to be working? It's in the Debian > packages as far as I know - so it could be applied to 2.0, tested and a > new version could be released after 3 (?) weeks. Sure, I'd have no problem with 2.0.1 including the preforking patch. It doesn't change the interface to the application, only its behavior for large connection loads. > I'm no friend of collecting a huge number of changes and release rarely - > I prefer releasing after every single change. We have to collect all of the external changes and release them at once. The internal changes can evolve over time so long as they look the same from an interface perspective. > [..] > > It was meant to be a 4 - 6 month stopgap and changeover solution, but > > instead became the 5 year production system. This happens ALL THE TIME. > > What's the consequence? We delay dbmail and put more features in? The > preforking patch is a candidate. That takes a while so you could finish > the sieve patch? That takes a while so we could do the header marking. > That takes a while ... never ending storing :-) > Release early, release often. What I'm saying is that we aren't just "getting 2.0 out there so that we can start on 2.1". Rather, we must "get 2.0 out there so that people have a stable system to rely on for another 1-2 years". There's no slippery slope here. The criteria I'm talking about for changes prior to 2.0 is very discrete: does the change involve breaking user interfaces and/or database interfaces? If not, save it for 2.0.x. If so, is the change something that we're going to want to be already using a year from now? If not, save it for 2.1. If so, go for it. Aaron --
