Re: DBD::mysql path forward

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.