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

Re: Perl 5.10.1

Thread Previous | Thread Next
Aristotle Pagaltzis
June 24, 2009 03:00
Re: Perl 5.10.1
Message ID:
* Nicholas Clark <> [2009-06-24 11:35]:
> 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.

Does an ecosystem of patches that may be just as slightly dodgy
help anything? If we encourage OS vendors to package stable perls
with slightly dodgy patches, what appreciable difference does
this make to end users?

And anyway, 5.10.0 *was* released in a slightly dodgy state. So
the question is not about whether slight dodginess will follow if
the strategy changes, but how to adopt the strategy to deal with
the slight dodginess that does inevitably go out into the wild
every so often.

I’m not advocating to roll a release the moment a fix for an
accidentally released regression is checked in either. There has
to be some testing, obviously.

But I think what’s absent from much of the debate right now is
that the reality is that regressions do get released; 5.10.0 did
happen. Because another reality is that users can’t be made to
care about release candidates no matter how much we’d like them
to and how annoying that may be to pumpkings who want to do their
work diligently.

Aristotle Pagaltzis // <>

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