develooper Front page | perl.perl5.porters | Postings from March 2007

Re: Isn't it High Time for perl-5.8.9?

Thread Previous | Thread Next
Nicholas Clark
March 14, 2007 06:31
Re: Isn't it High Time for perl-5.8.9?
Message ID:
On Mon, Mar 12, 2007 at 12:26:17AM +0200, Shlomi Fish wrote:
> Hi all!
> I believe it's high time to release a new maintenance release of the 
> perl-5.8.x branch. There are several bugs that I'm aware of in perl-5.8.x. 

So do I. I've been working on it.

> However, I'm sure there are many other bugs that bother people. Last time I 
> checked, many major CPAN modules were broken with bleadperl, so I think we 
> should make another perl-5.8.x while people are waiting.
> "Release early, release often." ;-)

It's actually rather hard work to make a core perl release.
There are so many potential ways to mess it up. It's not like the average
CPAN module, which has some dependencies, but not all of CPAN *AND* the
company code you can't see. Remember the fun when Test::Builder broke?
Messing up a core release could be worse.

Particular fun bits are

1: Getting the code stabilised and removing any signs of smoke from the
   smokers. (And getting VMS happy is always fun)
2: Wondering if anyone has actually tested anything with maint before the
   first release candidate
3: Issuing the first release candidate and wondering if anyone is going to test
4: Wondering how to deal with any bugs anyone reports on the release candidate.
   (Trying to work out which change(s) caused them. Trying to work out if
    those changes should be reverted, because the end user code is buggy.)
5: Wondering if it's actually time to call it a release, or whether something
   will show up 6 hours after the official release is blessed, which will make
   it a rather embarrassing mistake.

Number 5 is the worst bit.

Given that it's wise to give it at least a week between a release candidate
and a release, it means that you can't fix anything without a week's delay.
During which time the duff release will be spreading far and wide.

5.8.4 was within 24 hours of such a mess. Had I released a day earlier,
a lot of e-mail would have bounced, because one-or-other mail delivery
system was using suidperl in a way that no-one suspected, that specifically
did exactly what the core documentation said not to do.

> Oh, and let me know if there's anything I could be of help in this regard.

1: Specifically, it would be useful if someone were able to figure out what
   still needs doing with podulators backwards compatibility. See

   I'd like to merge all the upgraded podulators to maint, as it will fix bugs
   and improve things. But I don't want to break backwards API compatibility.

   If no-one else does this, I may do it. Or I may decide that it's not going
   to happen because it will take too much of my time.

2: Specifically, it would be useful if someone were able to test that the
   current blead version of Storable builds and passes tests on older perl
   versions in various configurations, at least back to 5.005_04

   Storable needs a non-development CPAN release before it can be merged into

3: More generally, it is very useful if everyone gets maint, eg from

   rsync -avz rsync://

   and builds their work/private code with it (and runs it). Run CPAN
   modules' regression tests with it is one thing, but actually building
   and using it on a sandbox version of your company development environment
   is in a different league. I see from your other message that you're already
   doing this. Thanks.

Nicholas Clark

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