please don't reply-all on mailing-lists, thanks to the kill-dupes feature of dbmail i get only one copy, but your offlist one is faster and missing the list-headers
Am 22.08.20 um 02:09 schrieb Sandino Araico Sánchez: > On 21/08/20 18:24, Reindl Harald wrote: >> tell me something new :-) >> >> after the expierience with 3.0 and 3.1 which needed a ton of fast fixes >> from Paul and the current prject inactivity update to 3.2 is not >> schduled for now > Project has been active on Github for some months. still wrong point in time given the amount of other work >> there where a ton of "fun" from empty mails via POP3 over crashes of >> lmtpd when a native autoreply got triggered to subtle reconstruct bugs >> depending on imap clients while others prteneded it#s working just fine >> both times > > Those kind of issues could be expected in development branch. i talk about the hundrets of ours to get 3.0 and 3.1 *final* releases stable and stop the ongoing customer complaints about broken emails > Many stability issues have been fixed in 3.2 branch. It should be more > stable than any 3.1 release. that was said about 3.1 back that time too :-) > Depending on ehich 3.1 release you are, you might need to apply SQL > changes manually to the table structure. It might be helpful if you > compare the database schema with a newly installed one. it might be helpful when the package contain migration sql-files at least one sequence column i know about needs also taken care of in the admin backends which have capabilities to move mails between folders and users by update the dbmail database >> it's simply the wrong point of time to annoy endusers with email troubles anways, it's the wrong point in time, i have to stabilize major upgrades of our platform which includes the dbmail backends and don't mix such tasks with major upgrades don't see dbmail 3.2.x in 2020 here _______________________________________________ DBmail mailing list [email protected] https://lists.nfg.nl/cgi-bin/mailman/listinfo/dbmail
