Re: DBD::mysql path forward

Michael, why can't you accept moving forward under a new module name?  Why does 
it have to be under the old name?  When people purposefully want to upgrade they 
purposefully choose the new module name in order to do so.  What is the actual 
problem in that? -- Darren Duncan

On 2017-11-09 10:59 PM, Michiel Beijen wrote:
> On Fri, Nov 10, 2017 at 7:16 AM, Darren Duncan <[email protected]> wrote:
>> I agree with everything Dan said here.  Its what I proposed, in fewer words.
>> Do all new development under a new name, including all of Pali's work, and
>> leave the current name for a product with no further effort applied to
>> develop it. -- Darren Duncan
>
> This is NOT an option to me - it simply can't because the world moves
> forward and because of bitrot. The 'old' version - the version that
> works for most people, the current version of DBD::mysql, the one
> which would then receive no more maintenance as it is no longer
> compiles with the latest version of libmysqlclient and it does not
> compile with libmariadb. This will only get worse in the future.
>
> I'll stick with my earlier proposal - I'll propose to go back to the
> *current* latest DBD::mysql release which does not break backcompat
> for our users; add the patches that we discarded when we rolled back
> one by one, such as testing on many different lib/db options, memory
> leaks and so on, and make a new release so we can be on the move
> again.
>
> If possible I'd want to add back the *breaking* unicode changes that
> were introduced but they should be either in a separate namespace OR
> under a specific configuration option.
> Currently this whole thing has cost us loosing MONTHS of progress and
> then MONTHS of nothing and that is simply not good.
>
> Patrick: let me know if you're OK with this and then let's get start again!