Aaron Stone wrote:
What wont-fix bugs in 2.0 are resolved in 2.1 without header caching?
recent flag (bug #97) comes to mind. I know I said I would try to fix that one
for 2.0, but that was before the sort breakage surfaced.
Also, insertion will be more robust in terms of mime parsing because of gmime.
Generally, there's not much difference between 2.0 and cvs-head yet from the
client's point of view. Internally, things have changed quite a bit for imap and
insertion.
If we make a concerted effort, 2.1.0 can be released in no time at all. In
fact, I'd very much like to release 2.1.0 before I start depending on the
header tables.
Where 2.1.0 involves mostly cleanups and rewrites of the imap server? I
guess I'm a little out of touch with just what's happened so far in 2.1
:-\
Mostly imap stuff, yes. But like I said I'm also reshuffling the insertion code
and I'm adding a lot of test-code.
If we're still keeping with the Linux kernel-style version numbers, then
2.1.0 is a release only developers should be touching. Even if 2.1.0 is
rock solid, I fail to see how that benefits regular users -- the current
release plan on the wiki (albeit from Nov. 2004) says that you want to do
header caching in 2.1.1.
True. But before I move on the 2.1.1, I need a 2.1.0 release first right?
So a user who things, "gee 2.1.0 is rock solid,
I'll just use that" will have to go right back to 2.0.x if there's a
security release or other bugfix release, since going to 2.1.x might
involve database changes.
The database changes I have in mind will be forward compatible. That is: 2.1.x
code will use more tables, but 2.0.x will be able to use the same database
without a problem. So people will be able to use both 2.0 and 2.1 connecting to
the same database *at the same time*.
I don't mind working on 2.0 when it comes to bugs. But with just two people
actively working on the code at the moment, maintaining and actively moving
forward two different branches just seems a bit much.
Just a quick look at the 2.0.4 wiki gives me the impression that 2.0 is in
a combined bugfix / code speedup mode. Basically, the idea is that most
people are on 2.0 now, and things are getting smoother and faster with
each release. That's a good thing in my book!
agreed. 2.0 is definitely not abandon-ware. It's what all my clients use.
I do agree here. Silent failures are not good. But they've also been in
there since 2.0.0.
So what? You uncovered how bad this bug is by silenty recognizing
US-ASCII, which was the cornerstone of c-client's SORT request. If a
client requests ISO-8859-1, we recognize and silenty fail on that, too. We
just happen not to have received a bug report from someone whose client
issues the command "SORT (REVERSE ARRIVAL) ISO-8859-1 ALL". It's a bug and
needs to be fixed.
There's no discussion there. Just whether it should be targetted at 2.0. If you
feel strongly about fixing it for 2.0, I say excellent. Perhaps you can find an
elegant solution to this problem :-)
If you're saying that there are no valid arguments to SORT, then let's
take it out of the capabilities. It's just by luck that no client is
asking for something it actually relies on DBMail returning sane values
for. We're offering to do this SORT thing, but all we give back is
garbage. Why offer in the first place?
Because the SM users love it?
--
________________________________________________________________
Paul Stevens [EMAIL PROTECTED]
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands_______________________________________www.nfg.nl
