I'm relatively new to dbmail development, and have been lurking for quite a while and quietly following the latest CVS. Honestly, I do not believe dbmail 2 should even be in RC phase. Maybe there should be a feature freeze, but most of the changes coming out are changes that I think should be implemented for a 2.0 release. Especially something like table_prefixes (At least dbmail_*). In a day and age where everyone is moving everything into the database, not prefixing the tables would instantly put dbmail at a huge disadvantage and would probably be the number one complaint people had about the 2.0 series (besides filtering and header caching).
Many people (especially old dbmail 1 users) will be expecting a drastic change from dbmail 1 to dbmail 2. However I've seen alot of people suggest holding off on some things for dbmail 2.1 - I think that's a mistake. Point releases are maintennance releases. People will expect regular maintennance releases, however the initial release of a new version should contain most of the drastic changes that have been discussed on this list for the past couple of months. I honestly suggest reseting the RC numbering, implementing most of the changes that were talked about, and then starting the RC process over again. Most people will try dbmail2 once when it comes out. They're not going to want to see critical features left for a future release - they'd rather see it released with support for these things, and then implementation bugs with them cleaned up in point releases. My humble opinion. But honestly, why go through a painful upgrade from dbmail 1 to dbmail 2, and then from dbmail 2.0 to dbmail 2.1 - that's ridiculous. Already implementing the table prefixes was a big headache (for me anyways), you're not going to want a large percentage of the dbmail userbase doing that twice, from 1 to 2, and then 2 to 2.1. > Atupid, irrelevant changes in RC like this, are not acceptable. Leave > it as is, save it for 2.1 > > Dan > > > Aaron Stone wrote: > > I'd like to have the source distribution for 2.0 look a little tidier than > > previous release candidates and the 1.x sources. I just tested this out > > with a > > fresh CVS checkout and it works well: > > > > $ cd dbmail > > $ mkdir src > > $ mv *c *h conf* ac* libtool Makefile* buildtools/ > > sort/ auth/ mysql/ pgsql/ oracle/ man/ src/ > > $ ls > > AUTHORS INSTALL.exim VERSION > > BUGS INSTALL.postfix contrib > > COPYING INSTALL.qmail dbmail.conf > > CVS NEWS mysql2pgsql > > ChangeLog README sql > > EXTRAS THANKS src > > INSTALL TODO test-scripts > > > > > > Yes, no, maybe? > > > > This format also makes clear just how much some of the documentation needs > > to > > be edited. There's a few parts that are just a jumbled mess of instructions. > > > > Aaron > > > > PS - For those sore about the database table prefixes, please be so kind as > > to > > look past that for a moment. We'll figure something out that we can all live > > with, with respect to the tables prefixes issue, and please do help out on > > rc8. > > ----- "Any sufficiently advanced bug is indistinguishable from a feature." -- Rich Kulawiec [EMAIL PROTECTED]
