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 <dar...@darrenduncan.net> 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!
