Hi Darren, Dan, On Fri, Nov 10, 2017 at 7:16 AM, Darren Duncan <dar...@darrenduncan.net> wrote: > On 2017-11-09 8:32 AM, Dan Book wrote: >> >> It seems to me like the remaining option that can make everyone "happy" is >> the >> previously-suggested option of maintaining a legacy branch and doing new >> development (reinstating 4.042) in another branch which will be released >> as a >> new distribution, like DBD::mysql2, by the same maintainers. (I would not >> favor >> DBD::MariaDB as a name, since this new distribution would also be the >> favored >> way to connect to MySQL.) After doing so DBD::mysql can be deprecated, >> with >> migration instructions added to the docs, and only receive critical >> security >> fixes if anything. If done this way the community should not be fractured; >> the >> current module will simply be abandoned for future development, all >> support and >> maintenance will move to the new one. Patrick and Michiel, what do you >> think? > > I agree with everything Dan said here. Its what I proposed, in fewer words. > Do all new development under a new name, including all of Pali's work, and > leave the current name for a product with no further effort applied to > develop it. -- Darren Duncan
This is NOT an option to me - it simply can't because the world moves forward and because of bitrot. The 'old' version - the version that works for most people, the current version of DBD::mysql, the one which would then receive no more maintenance as it is no longer compiles with the latest version of libmysqlclient and it does not compile with libmariadb. This will only get worse in the future. I'll stick with my earlier proposal - I'll propose to go back to the *current* latest DBD::mysql release which does not break backcompat for our users; add the patches that we discarded when we rolled back one by one, such as testing on many different lib/db options, memory leaks and so on, and make a new release so we can be on the move again. If possible I'd want to add back the *breaking* unicode changes that were introduced but they should be either in a separate namespace OR under a specific configuration option. Currently this whole thing has cost us loosing MONTHS of progress and then MONTHS of nothing and that is simply not good. Patrick: let me know if you're OK with this and then let's get start again! -- Michiel
