Darren,
Thank you.
Yes, you are correct about prior discussions. How do we handle releases
of having a DBD::mysql and a DBD::mysql2, in terms of people knowing
"this is the old branch with no possibly breaking changes" vs. "this is
the new branch" ? It's been pretty simple for the 14 years I've been
working on DBD::mysql, my main concern being, how do the various
distributions handle this sort of thing? I suppose deal with each OS
distributor on a case-by-case basis.
Michiel and Pali too - what do you think of what Darren is saying?
My main concerns in all of these discussions are:
1. No fragmentation
2. Stability per Night Light's previous email
3. Choice for users to decide which driver to use
4. Single project under one roof
5. Contributors who work hard on this driver get credit
Let's do this ! :)
Regards,
Patrick
On 11/7/17 4:19 PM, Darren Duncan wrote:
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.
