Re: DBD::mysql path forward

[email protected] ("H.Merijn Brand") Thu, 9 Nov 2017 13:01:19 +0100
Newsgroups	perl.dbi.dev,perl.dbi.users
Message-ID	<[email protected]>
On Thu, 9 Nov 2017 12:32:00 +0100, [email protected] wrote:

> > Satisfy the above - and you do get the privilege of being a maintainer
> > of a central module with 15+ years of history.  
> 
> Why should I be interested in maintaining something from which users
> want impossible things?

  "I can resist anything! (except temptation)"

I, like Peter, have backward compatibility high in my goals.

e.g. I dropped 5.005 supprt on Text::CSV_XS only in June 2012. The
reasons to keep it working under 5.005 was that it was relatively
little extra work. I dropped it, as it seriously blocked further
development and support features my *user-base* asked for. Lucky me
for being part of my own user-base, so I understand the requests.

In July 2016 I dropped 5.6.0 and 5.6.1 support. Not because it slows
development, but because these two versions do not build anymore and
do not support the modern toolchain. Not because the community or a
part of the community thinks the users should upgrade to a more recent
"stable" version of perl. Yes, I know 5.6.2 is from 2003 and 14 years
old in 6 days and 5.8.0 is even older, but maintaining a module that
serves almost 1000 other modules on CPAN (last time I counted, it was
997 direct or indirect dependencies) brings a burden of responsibility

This is how the river works: If I break this module, at least 997 other
modules will break, and that is CPAN only. What about DarkPAN?

If you do not want that burden, I'd strongly advice you *NOT* to take
on the job of (co)maintaining DBD::mysql. Period.

I *see* your wish to improve it (for whatever value of improvement).
This was exactly the reason I took maint on Text::CSV_XS: I wanted,
maybe even required, new features. The original author/maintainer was
not interested and/or motivated enough to do it and he passed the
module on to me. By that time I HAD NO IDEA what the impact of doing so
had. NONE! *I* wanted new feature and improvements, and he agreed.

It took me years to fully understand the implications of my actions.

So, currently I test a release on 7+ architectures and over 150
versions of perl before I release and additionally I test the latest
release against all of those 997 modules if the new release causes any
of those deps to show new failures (compared to the old release). (Some
of these modules are currently un(der)maintained and won't build on
5.24+ for whatever reason, so if that breaks, it is not my fault.

Additionally I run speed-tests: I compare the last 20 releases for
typical use and compare the speed. If it drops out of the noise range,
that is a blocker to release, even if the new feature request is wanted
by several requestors or communities.

If you're not up to this challenge, don't do it. There are companies
depending on DBD::mysql, and they won't be your friend if they need to
modify millions lines of code if you find a new API fit better to the
new features thereby breaking old code. Backward compatibility is
important. More than you think.

How angry would you be if we broke DBI?

-- 
H.Merijn Brand  http://tux.nl   Perl Monger  http://amsterdam.pm.org/
using perl5.00307 .. 5.27   porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/        http://www.test-smoke.org/
http://qa.perl.org   http://www.goldmark.org/jeff/stupid-disclaimers/
signature.asc (application/pgp-signature, 473 B)