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.