develooper Front page | perl.perl5.porters | Postings from April 2004

Re: CPAN-newer-than-release for 5.8.4 RC1 (was Re: 5.8.4 RC1)

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
April 7, 2004 02:39
Subject:
Re: CPAN-newer-than-release for 5.8.4 RC1 (was Re: 5.8.4 RC1)
Message ID:
20040407093905.GA701@plum.flirble.org
On Tue, Apr 06, 2004 at 04:09:05PM -0700, Randal L. Schwartz wrote:
> >>>>> "Nicholas" == Nicholas Clark <nick@ccl4.org> writes:
> 
> Nicholas> If they weren't in blead by the code freeze deadline they didn't get in.
> 
> But RC1 isn't a code freeze.  Had I known you were getting close to
> RC1, I would have sent this message a few days earlier.

The specific code freeze date was first announced 6 months ago.
The most recent mention of it was in the perl5-porters summary last week:

http://use.perl.org/article.pl?sid=04/03/30/100238&mode=nested&tid=12

> These *should* go in for RC2.

There may not be an RC2.

In my view there is no mandate that *anything* should go into a release.
And specifically I am favouring stability over uptodateness. I'm the one
who gets egg on his face if a release is duff, and I'm being careful.

"Code freeze" actually is getting implemented as "no new code" after the
release candidate. Between that and release, things only roll back
The need for another release candidate implies that the first candidate
wasn't up to the job, so if there is cause for another RC (which only delays
the final release and hence cuts the time between it and the next code freeze)
minor, stable things can go in. In turn, the policy of time based releases
is specifically designed to prevent the mad rush of patching that used to
happen just before a stable release - a mad rush of patching being the least
conducive thing to code stability.

The policy of nothing new more a save-my-face option - the intent is that
release will contain code that is either

a: what was in the last release candidate
b: what in the previous stable release

The intent is that if anyone reports a core bug tickled by a CPAN module
in the new release itself, then the bug will also be visible either in the
release candidate, or it will turn out that the bug was present in the
previous stable version. Either way, I had not prevented the bug from being
reported prior to the stable release, and an opportunity had existed to
report that the release candidate was buggy. (This fails if the bug is
caused by the interaction of changed and unchanged code)

If the author of a CPAN module makes a release just before "code freeze"
(whenever that might be relative to RCs or perl releases) and 3 days later
someone finds a major but subtle bug in it, then the author can release a
new version PDQ. This minimised that damage.

However, if I roll that module in and make a perl release WITHIN those 3 days,
then perl has that duff module. And I can't make a new perl release within
3 days, and I'm not sure if I want to make a whole new release if it
transpires that one module in lib/ is embarrassing. And most people don't
keep systems up-to-date, so many people aren't going to download the newer
fixed versions from CPAN. Anecdotal evidence about ISPs reluctance to
install anything from CPAN, even useful stuff not in the core, suggests that
many perl installations are the core tarball only. Hence I'm mindful of the
need to keep core releases good and clean. The price for that is that they
might be slightly out of date. In other words, they're not bleeding edge.
But for a goal of stability, this feels like the right thing.

I want people to be able to drop the entire new release in place, and find
that all their acceptance tests pass first time. And I want this for 5.8.4,
5.8.5, 5.8.6, 5.8.7 etc. Which means that I need to be careful. The
probability of me not screwing up any of those releases is exponential
with the number of releases. The probability of screwing up any release
is exponential with the complexity. (I have to independently not screw up
each part in order to not screw the whole up). If there's a 5% chance of
any change being a problem, then I only have to make 14 changes before it's
51% likely that I have at least 1 problem.

I realise that it looks somewhat silly if perl ships with modules that are
slightly out of date. But it looks stupid if perl ships with modules that
are broken, and it's highly visible if a new "stable" release comes alone
shortly after to fix them, advertising the very cock up we'd rather the
public didn't notice.

Nicholas Clark

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About