I would suggest to communicate with all people behind cpan modules which uses mysql_enable_utf8.
https://grep.metacpan.org/search?size=20&q=mysql_enable_utf8&qd=&qft= They should know if their modules are expecting old broken or behavior of DBD::mysql or not. I would expect that are modules which needs correct behavior as not all perl people expect such bugs... They can update their modules to be compatible with both old buggy behavior and new correct. Months ago I wrote update for DBD::mysql POD documentation which mention example how to achieve it: https://github.com/perl5-dbi/DBD-mysql/pull/119/files Meanwhile DBD::mysql can try to play with "conflicts" relationship in META.json to prevent installing one of the above cpan module which depends on broken DBD::mysql until maintainer of that module fixes it. https://metacpan.org/pod/CPAN::Meta::Spec#Prereq-Spec I have never uses "conflicts" in META.json, so I do not know if it is working correctly in all cpan clients, but according to documentation it is a way how to achieve that users would not upgrade DBD::mysql to new version if they have installed another module which needs old DBD::mysql. Has anybody experience with "conflicts" in META.json? Also this would mean to prepare list of all of those cpan modules and add them into "conflicts" section in DBD::mysql's META.json. This can be tested e.g. by releasing engineering/beta version on cpan. On Tuesday 12 September 2017 21:45:11 Patrick M. Galbraith wrote: > Darren, > > I agree with this as well, with the exception of 4 and 5, keeping 5.0 "pure" > to the new way of doing things. > > For releases, I think I want to understand what this will mean. Sooner or > later, a release shows up in as a distribution package, installed on the OS, > and I want to know what the way of communicating that to the users and > vendors so expectations are met. That's another question of "how do we > handle that?" and "how do we inform an OS packager/vendor, what to do? > > Thank you for the great discussion! > > Patrick > > On 9/12/17 2:05 PM, p...@cpan.org wrote: > >On Tuesday 12 September 2017 19:00:59 Darren Duncan wrote: > >>On 2017-09-12 8:54 AM, Dan Book wrote: > >>>On Tue, Sep 12, 2017 at 11:04 AM, Patrick M. Galbraith wrote: > >>> Pali, > >>> Yes, I agree, we'll have to create a fork pre revert and stop > >>> accepting PRs How might we allow people time to test the fixes > >>> to give them time? Just have them use the fork, I would > >>> assume? > >>> > >>>To be clear, this sounds like a branch not a fork. If your plan is > >>>to reinstate the mysql_enable_utf8 behavior as in 4.042 rather > >>>than adding a new option for this behavior, then branching from > >>>4.042 seems reasonable to me; but you should be very clear if this > >>>is your intended approach, as this is what led to many people > >>>corrupting data as they send blobs to mysql with the same > >>>mysql_enable_utf8 option, and expect them to accidentally not get > >>>encoded. > >>Assuming that broken Unicode handling has been in DBD::mysql for a > >>long time and that users expect this broken behavior and that fixing > >>DBD::mysql may break user code making those assumptions... > >> > >>I strongly recommend that another thing happen, which is > >>re-versioning DBD::mysql to 5.0. > >> > >>A declared major version change would signify to a lot of people that > >>there are significant changes from what came before and that they > >>should be paying closer attention and expecting the possibility that > >>their code might break unless they make some adjustments. Without > >>the major version change they can more easily and reasonably expect > >>not having compatibility breaks. > >> > >>Part and parcel with this is that only DBD::mysql 5.0 would have the > >>other changes required for compatibility with newer MySQL versions > >>or features that would be the other more normal-sounding reasons to > >>use it. > >> > >>So I specifically propose the following: > >> > >>1. From now on, DBD::mysql versions 4.x would essentially be frozen > >>at 4.041/4.043. They would expressly never receive any breaking > >>changes (but see point 3) and in particular no Unicode handling > >>changes. They would expressly never receive any new features. This > >>is the option for people whose codebases and environments work now > >>and want to leave it alone. > >> > >>2. From now on, DBD::mysql versions 5.x and above would be where all > >>active development occurs, would be the only place where Unicode > >>handling is fixed and new MySQL versions and features are supported, > >>and where other features are added. Version 5.0 specifically would > >>have all of the backwards-breaking changes at once that are > >>currently planned or anticipated in the short term, in particular > >>fixing the Unicode. Anyone who is already making changes to their > >>environment by moving to a newer MySQL version or want newer feature > >>support will have to use DBD::mysql 5, and in the process they will > >>have to go through their Perl codebase and fix anything that assumes > >>Unicode is broken. > >> > >>3. As an exception to the complete freeze otherwise mentioned, there > >>could be one or more DBD::mysql 4.x release whose sole purpose is to > >>back-port security fixes or select other bug fixes from 5.x. Also > >>4.x could gain minimalist documentation changes to indicate its new > >>legacy status and point to 5.x. > >> > >>4. Optional bonus 1: If it is reasonably possible to support both > >>correct Unicode handling as well as the old broken handling in the > >>same codebase, I suggest DBD::mysql 5.0 could also have a user > >>config option where one could explicitly set it to make DBD::mysql > >>use the old broken behavior, while the default would be to have the > >>correct behavior. This would be analogous to Perl's "use > >>experimental" feature. The idea is that it would provide a > >>temporary stopgap for users migrating from 4.x where they could just > >>make the minimal change of enabling that option but they otherwise > >>wouldn't yet have to go through their codebase to fix all the > >>assumptions of wrongness. Using this option would cause deprecation > >>warnings to be emitted. Perhaps the feature could be lexical or > >>handle-specific if appropriate to help support piecemeal migration > >>to correct assumptions. Alternately it may be be best to not have > >>this option at all and people simply have to fix their code on > >>moving to 5.x. This matter is probably its own discussion, but the > >>key part is it only applies to 5.x, and meanwhile the 5.x default is > >>correct Unicode while 4.x freezes the old bad Unicode behavior. > >> > >>5. Optional bonus 2: A user config option could be turned on but all > >>that it does is emit warnings in situations where the Unicode > >>behavior was fixed, to prod users to check that particular spot in > >>their code that may have been impacted, this would be more like a > >>typical "use warnings" maybe. This is just a tool to help users > >>convert their code and find impacted areas. > >> > >>Note, 4.x versions have already been in use for a full decade, so > >>there shouldn't be new version fatigue. > >> > >>So Patrick and Pali and others, what think of my proposal? > >> > >>-- Darren Duncan > >I'm fine with it. Basically it means reverting to pre-4.043 code and > >continue *git* development there with increased version to 5.x. And once > >code is ready it can be released to cpan as normal (non-engineering) 5.x > >release. > > > >About optional points 4 and 5 we already discussed half a year ago we > >rejected it, because it was hard to implement and very hard to ensure > >that old broken behaviour would not be changed in future by some > >unrelated change.
