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.
