Front page | perl.perl5.porters |
Postings from March 2007
Re: Isn't it High Time for perl-5.8.9?
Thread Previous
|
Thread Next
From:
Nicholas Clark
Date:
March 14, 2007 06:31
Subject:
Re: Isn't it High Time for perl-5.8.9?
Message ID:
20070314133049.GQ5748@plum.flirble.org
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
it
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
http://groups.google.com/group/perl.perl5.porters/browse_thread/thread/d797dc96cc672037/a06bbf2bac451935?lnk=st&q=20060220060924.GA2500%40efn.org&rnum=1
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
5.8.x
3: More generally, it is very useful if everyone gets maint, eg from
rsync -avz rsync://ftp.linux.activestate.com/perl-5.8.x/
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