Re: DBD::mysql path forward

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.

So those people using "DBD::mysql" would not experience any changes in behavior 
from what they were used to and BLOB etc should not break.  Whereas people that 
want the Unicode fixes and other features would use the DBD::mysql2 and fix 
their code to be compatible with its breaking changes.

I thought this was settled, and takes care of your concerns, so it was just a 
matter of "make it so".

(Anyone replying to this message/thread, please do NOT include my personal email 
address as an explicit recipient, only send it to the list addresses, I will get 
those.)

-- Darren Duncan

On 2017-11-07 3:41 AM, Night Light wrote:
> For the reason of "silence":
> I've spoken to other users to hear that they have passively withdrawn from this
> discussion as they are not motivated to be part of a release where concerns
> about backwards compatibility are ignored. One of the users wrote earlier
> (replace the word "sector" with "release"):
>
> "When you're dealing with software that's purpose in life is to not corrupt
> data, and have data there tomorrow, you go out of your way not to break that
> promise. There's no point in being involved in this sector if you don't care to
> deliver on that promise."
>
> Re-releasing the 4.042 changes will break the contract of a long-standing
> interface and corrupt all BLOB data when using "do()". These changes do
> therefore more harm than good.
> Putting these utf8 changes in the freezer until a suggestion is made that will
> add the functionality instead of replacing it is not a sin. The PG driver has
> for instance also a similar issue open without plans to fix it anytime soon.
> https://rt.cpan.org/Public/Bug/Display.html?id=122991
>
> What is your objection against using the current 4.043 branch and work on
> outstanding fixes, do a pre-release, a period of time for people to test/try
> out, then release?