Re: DBD::mysql path forward

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