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

Re: Perl 5.10.1

Thread Previous | Thread Next
June 30, 2009 09:43
Re: Perl 5.10.1
Message ID:
On Tuesday 30 June 2009 09:35:56 Nicholas Clark wrote:

>    What I'm thinking might be best is having planned interval*s* to code
>    freezes for the maintenance branch. This is assuming that all bug fixes
> get into blead by someone-not-the-maint-pumpking, as has roughly been
> happening since 2003. Merging (cherry-picking) is assumed to run in
> parallel, with a minor lag to assess stability in blead. (Or whichever
> branch is the integration and "please CPAN smoke this")
>    So, 1 month after 5.14.0 is shipped is the cutoff to get fixes into
> blead for 5.14.1-RC1. 2 months after 5.14.1 ships is the cutoff to get
> fixes into blead for 5.14.2-RC2 etc.
>    This would mean releases at 1, 2, 3, 4, 5 and 6 months (then steady
> state at 6 months, or possibly even go to "build fixes and security issues
> only), which is 6 releases across 21 months, rather than 7 quarterly, but
> with releases concentrated where it matters more.

With the caveats that release candidates are a polite fiction that do not work 
in practice and that few outside p5p will be able to understand this schedule 
well enough to explain it to non-technical people, this idea sounds 

... if there can be multiple, rotating release managers.  That social 
bottleneck is as much a problem as are the technical bottlenecks.

> But even with a scheduled release policy, there's no guarantee that
> a: the bug would be fixed in the next release
> b: that the next release would happen on schedule

*Guarantee*, no, but there are ways to increase the likelihood of releases 
happening on schedule from the current low percentage to something in the 95% 

No scheduling practice of which I am aware can guarantee a).

-- c

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