Theo Van Dinter wrote:
On Sat, May 28, 2005 at 04:35:04AM -0400, Duncan Findlay wrote:
I'm -1 on this. We are close enough to 3.1 that that would be a pointless waste
of time.
We've been "close enough to 3.1" for ages, and a 3.1 release doesn't help fix
the bugs in 3.0 which people will continue to use.
done with that, we really don't need another one. These bugs are
relatively minor.
Actually some are relatively major.
Agreed. The (fixed) qmail header parsing issues caused by empty ident
strings and the (fixed) increasingly outdated IANA reserved blocks both
contribute heavily to FNs and FPs. The (also fixed) URL parsing issues
are also worth fixing for anyone who's stuck with 3.0 for a while.
Dan was ready to prepare a pre-release for 3.1.0 (until people started
checking tons of code in anticipation...) We are close to 3.1.0. We
The bigger issue is that trunk was unstable at that point. spamd still
exhibits random lock ups, for instance.
Somehow the 3.1.0 queue has gone from ~10 bugs to ~25 bugs too. If the
current goal is to get a 3.1-pre out I don't think the people doing bug
triage are aware of that.
don't need this distraction. Also, if we lasted so long between 3.0.2
What distraction? There are a handful of patches left (mostly backports from
3.1), and then the code is ready to go. There's someone (me) who's willing to
be the RM for 3.0.4... So how is this a distraction?
For a group who from previous conversations wanted to do the "release
often" thing, there seems to be a lot of resistance to releasing bug
fix versions... The original plan starting with 2.6 was to do this kind
of thing monthly, and new feature releases every 3-6 months, as a "fwiw".
We've not gotten anywhere close to that schedule.
Agreed with Theo. So long as the release notice is clear that it's a
maintenance release, outlines what was fixed and points out that no new
features were added, people can decide for themselves if they want to
bother deploying a 3.0.4 release.
Daryl
