I do not understand what (and how) your proposal with =2 solve. Probably nothing and people would again start after final release again complaining...
On Friday 10 November 2017 09:24:35 Night Light wrote: > 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! > >> > >
