On Thu, 9 Nov 2017 12:32:00 +0100, p...@cpan.org 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/
pgp9urdKfiWHI.pgp
Description: OpenPGP digital signature
