Patrick and Pali, each of you please respond to the lists to confirm that what I
say below is what you also understand is the primary plan, and if not, then say
why not; in prior discussion I recall you agreed with it.
Assuming they agree, the concerns of Night Light and those he is speaking for
should be handily satisfied.
The whole discussion on the mailing lists that I recall and participated in
seemed to consensus on branching DBD::sqlite in order to best satisfy the needs
of all stakeholders.
There would be one version control with 2 active release branches.
A maintenance branch would exist starting from the 4.041/3 release on which
further stable releases named DBD::mysql 4.x would be made, and the primary goal
of this branch is to not break/corrupt anything that relied on 4.041 behavior.
So people with legacy projects that just use DBD::mysql and made particular
assumptions on its handling of Unicode or Blobs etc won't have corruption
introduced because DBD::mysql changed its handling of those things. People
without knowledge of CPAN or the development process will get something that
just continues to work for them and doesn't corrupt. For all intents and
purposes this branch would be frozen but could have select security or bug fixes
that comply with the mandate and don't involve changing Unicode etc.
The master branch would then have all the short term breaking changes including
the 4.042 Unicode fixes and would have all the significant feature changes
including compatibility with newer MySQL major versions. All of its releases
would be under a new namespace such as DBD::mysql2 and start at version 5.0 to
signify that large changes happened which might possibly break code or cause
corruption if user code doesn't specifically account for the differences. Being
a different name this is strictly opt-in, so the only ones using DBD::mysql2 are
those that explicitly opted in to it, and by doing so they also opted in to
fixing anything with their code that needed fixing to not corrupt data while
using it.
The concept of having a single driver with toggled behavior eg a
mysql_enable_proper_unicode flag was already rejected as unwieldy to implement,
especially for such deep rooted changes as properly handling Unicode.
Note that I expect that most other higher-level projects that use MySQL would
NOT branch like this, instead having internal logic or their own toggle to work
with DBD::mysql vs DBD::mysql2, or a few may branch, but the key thing is that
branching DBD::mysql does NOT necessitate doing so in the rest of the ecosystem.
-- Darren Duncan
On 2017-11-07 12:07 PM, Night Light wrote:
Proposed, but no made decisions posted afterwards.
The last proposal is to re-commit the rejected 4.042 changes into the 4.043
master branch and only work on fixes that came after June.
The git issue that regards improperly encoding of BLOBs is opened on April 6th
(hence me sending the message to prevent a recurring cycle).
https://github.com/perl5-dbi/DBD-mysql/issues/117
On Tue, Nov 7, 2017 at 8:57 PM, Michiel Beijen wrote:
To me, the only real option is to make a new option in DBD::mysql;
mysql_enable_proper_unicode or the like which you would knowingly set
in your application code, which will expose the new behaviour. I
understand this is difficult, but I really think it's the only way.
If in the short term this is not feasible, it *could* be possible, in
my eyes, to release a DBD::mysql2 or similar that does *correct*
behaviour. Also in that case this is something the application
developer should set explicitly in his connection string.
This DBD::mysql2 or similar could live in another git repository, but
preferably in the same repo, and even in the same CPAN distribution as
DBD::mysql, and eventually the goal should be that they re-unite and
using DBD::mysql2 would really be the same as to use the
'mysql_enable_proper_unicode' option in DBD::mysql.
--
Michiel
On Tue, Nov 7, 2017 at 7:41 PM, Darren Duncan <dar...@darrenduncan.net
<mailto:dar...@darrenduncan.net>> wrote:
> My understanding from the last discussion on this matter is that it was
> agreed DBD::mysql would be forked such that the existing DBD::mysql name
> would be frozen at 4.041/3 indefinitely and that the 4.042 changes plus
any
> further feature development would take place under a new name such as
> DBD::mysql2 version 5.0.
