[Bioperl-l] dependencies on perl version

[Aaron Mackey]

Huzzah!

--
Aaron J. Mackey, PhD
Assistant Professor
Center for Public Health Genomics
University of Virginia
amackey at virginia.edu
http://www.cphg.virginia.edu/mackey


On Wed, Feb 6, 2013 at 12:58 PM, George Hartzell <hartzell at alerce.com>wrote:

> Fields, Christopher J writes:
>  > [...]
>  > Right, it took ~8 yrs to go from 5.8 to 5.10.  I'd like to point
>  > out that Python users are in the same boat: the Python version for
>  > CentOS 5 is 2.4.3, and Biopython requires a minimum of python 2.5
>  > (and recommends python 2.7).
>  >
>  > We can always state that perl 5.8 is supported for the upcoming
>  > Bioperl release, but we're dropping v5.8 support for any future
>  > releases.
>
> Do more than drop support for 5.8.
>
> The Perl community has put a transparent and predictable process in
> place for releasing [generally] better versions of the language.  It
> means that Perl has a chance of continuing to be relevant, attracting
> new talent and actually *fixing* some of the s&%t that gives Perl a
> bad rap.  It gives people something to plan around, no one should be
> surprised that v 5.X.Y is coming out in mid 20ZZ.
>
> BioPerl should do the same thing, declare a release policy that trails
> along with the Perl release schedule.  Keep it simple and no one can
> argue with it.  Support Perl releases as long as the releases
> themselves are supported.
>
> Rather than expending energy supporting out of date platforms, put the
> energy into being modern (or Modern...), better distro building and
> packaging, testing, documentation and releasing so that the process of
> staying current is painless.
>
> Look forward.  Keep it interesting and fun.
>
> Everyone running Mac OS 9 on their Pismo, raise your hand.  Anyone
> make their living running sequencing gels in Plexiglas doohickeys on
> their lab bench?
>
> I'm not suggesting that the BioPerl community is free to make
> arbitrary and capricious changes that makes it difficult for *anyone*
> to get anything done.  Churn is a waste of time.
>
> But why should the all-volunteer BioPerl community be stuck supporting
> code from 12 years ago because it's cost effective for someone else to
> avoid spending *their* $/time/people to stay up to date.
>
> Those sites that value stability/maturity/stagnation so highly have
> already accepted the cost/difficulty of nailing one of their feet to
> the floor as they try to run forward.  They recognize and depend on
> the benefits of having that stable base but generally they've also
> accepted the costs associated with their restrictive choices.  They
> know how to pull in separate kernel/driver updates so that they can
> actually run on nearly modern hardware.  They know, and live with, the
> fact that they're not going to have access to the shiny new stuff.
> And they know how to stay up to date, when they need to, with the
> software that their users need to be competitive (e.g. BioConductor
> and R).
>
> As long as (if/when...) updating a BioPerl release is something that
> can reliably happen with a few cpanm invocations then the sites that
> otherwise favor punctuated equilibrium will learn to handle gradual
> change.
>
> Those folks that are "stuck" on older releases always have the option
> of supporting professional Perl programmers to keep older releases
> going, backport changes, etc....  They're already buying support for
> their platforms (or freeloading and coping), let them put bread on the
> table at one of the bioinformatics consultancies or labs if they have
> something special they need.
>
> Have fun.  Use sharp tools.  Do cool science.  Build cool things.  No
> one is paying you to be backwards compatible with the previous
> millennium.
>
> g.
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/bioperl-l
>