develooper Front page | perl.perl5.porters | Postings from June 2009

Re: Perl 5.10.1

Thread Previous | Thread Next
Nicholas Clark
June 24, 2009 03:13
Re: Perl 5.10.1
Message ID:
On Wed, Jun 24, 2009 at 05:55:35AM -0400, David Golden wrote:
> On Wed, Jun 24, 2009 at 5:34 AM, Nicholas Clark<> wrote:
> > Many end users, like it or not, are using the vendor supplied perl. Be that
> > an OS vendor, or the internal vendor in their company. And, like it or not,
> > many vendors package up whatever is current, and stick to that. So if there
> > are frequent, slightly dodgy releases, we end up with an ecosystem of many
> > dodgy releases, each with different bugs to work round. And a reputation for
> > slighty dodgy releases. And upgrade roulette - gambling that the new release
> > will not introduce bugs worse than the bugs that it fixes.
> Options:
> (a) ecosystem of many, frequent slightly-dodgy releases, each with
> different bugs
> (b) ecosystem of few, ancient releases, each with different bugs
> I would argue that the number of bugs in (b) is higher than in (a)
> simply due to elapsed time.  Option (a) works when number of bugs
> fixed per release is greater than number of bugs introduced.

Number of bugs, yes.
Number of different bugs, no.

I don't like regressions, full stop.

I consider creating new bugs, *that people then have to work round anyway*
to be a greater sin than fixing existing bugs *that people are already working
round*. I see the former as creating more work, given the assumption that
people rarely upgrade.

And yes, I do care about people who rarely upgrade. I don't want to cut them
off, because they don't have to choose to use Perl, and if we make it harder
for them, the next time they upgrade they may choose something else.

Clearly we differ.

Nicholas Clark

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About