Forking would take away my concerns (thank you all for suggesting that) but one thing pops into my mind: A decision to fork a mature module is not a light decision and should only be considered as a last resort (when ran out of all options). So far it is all based on the opinion of only one developer who finds it hard or probably impossible to implement.
Can before forking at least a second person with C knowledge open dbdimp.c and measure if it is indeed unfeasible to make the module backward compatible by adding an option as suggested? Michiel, do you know C? Can you do that 5-minute check? The breaking is due to the fact that the prepared SQL statement and the bound parameters will be apart from what is returned from MySQL is encoded as well. The mysql_enable_utf8/mysql_enable_utf8mb4 flags already arrange logic to set if utf8 encoding/decoding should be done or not. I'm not a C expert but this is what I find in dbdimp.c of 4.042 about it: dbd_st_prepare_sv function: bool enable_utf8 = (imp_dbh->enable_utf8 || imp_dbh->enable_utf8mb4); get_statement(aTHX_ statement_sv, enable_utf8, &statement, &statement_len); dbd_bind_ph function: bool enable_utf8 = (imp_dbh->enable_utf8 || imp_dbh->enable_utf8mb4); bind_param(&imp_sth->params[idx], value, sql_type, idx+1, enable_utf8); Would changing that into the following make the module backwards compatible? bool enable_utf8 = (imp_dbh->enable_utf8 == 2 || imp_dbh->enable_utf8mb4 == 2); enable_utf8 0 = no encoding of input and only decoding of output enable_utf8 1 = decode only output (4.043 mode) enable_utf8 2 = encoded input and decode output (4.042 mode) On Fri, Nov 10, 2017 at 8:37 AM, Darren Duncan <dar...@darrenduncan.net> wrote: > Michael, why can't you accept moving forward under a new module name? Why > does it have to be under the old name? When people purposefully want to > upgrade they purposefully choose the new module name in order to do so. > What is the actual problem in that? -- Darren Duncan > > On 2017-11-09 10:59 PM, Michiel Beijen wrote: > >> On Fri, Nov 10, 2017 at 7:16 AM, Darren Duncan <dar...@darrenduncan.net> >> wrote: >> >>> 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! >> >
