Hi! I'm responding below.
On Tuesday 07 November 2017 13:19:23 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
~~~~~~~~~~
DBD::mysql
I hope you are talking about DBD::mysql there...
> 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.
As those people or projects misuse some internals of perl we cannot
guarantee anything such that which may be broken or changed by updating
any module from cpan or external source not related to DBD::mysql.
Maintaining such thing is something what I believe nobody wants. For
sure I'm not.
As already stated more times, if there is some code which depends on
some internals, it should stay conserved in tested version as it can
break by updating anything (also unrelated). There is no other option
how to achieve that code stay working and does not corrupt something
else.
> People without knowledge of CPAN or the development process will
> get something that just continues to work for them and doesn't corrupt.
As explained above (and also in past) it is not possible to guarantee.
> 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.
Are you going to maintain that branch with all problems which it brings?
Or is there anybody else who want to maintain such crap?
If not, then it does not make sense to talk about this. Because nobody
expressed that is going to do such thing for 6 months which is really
large amount of time.
> 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.
