Front page | perl.perl5.porters |
Postings from April 2010
Earlier this week, I sent mail suggesting that we begin to consider
what tickets might be candidates for inclusion in the next maint
release, Perl 5.12.1.
A couple of porters have mentioned that they'd like a definitive
statement on what goes into a maint release. Historically, the
only requirement for getting a change or update into a maint release of
Perl has been that it not break backward compatibility.
After the heroic effort it took to get Perl 5.10.1 released, Dave
Mitchell led a discussion to help reach us reach a rough consensus
about what future maintenance releases of Perl would look like.
Based on that discussion, these are the ground rules for future maint
releases of Perl:
* New releases of maint should contain as few changes as possible.
If there is any question about whether a given patch might merit
inclusion in a maint release, then it almost certainly should not
be included.
* Portability fixes, such as changes to Configure and the files in
hints/ are acceptable. Ports of Perl to a new platform, architecture
or OS release that involve changes to the implementation are NOT
acceptable.
* Documentation updates are acceptable.
* Patches that add new warnings or errors or deprecate features
are not acceptable.
* Patches that fix crashing bugs that do not otherwise change Perl's
functionality or negatively impact performance are acceptable.
* Patches that fix CVEs or security issues are acceptable, but should
be run through the [email protected] mailing list
rather than applied directly.
* Updates to dual-life modules should consist of minimal patches to
fix crashing or security issues (as above).
* New versions of dual-life modules should NOT be imported into maint.
Those belong in the next stable series.
* Patches that add or remove features are not acceptable.
* Patches that break binary compatibility are not acceptable. (Please
talk to a pumpking.)
Getting changes into maint-5.12:
Historically, only the pumpking cherry-picked changes from bleadperl
into maintperl. This has...scaling problems. At the same time,
maintenance branches of stable versions of Perl need to be treated with
great care. To that end, we're going to try out a new process for
maint-5.12.
Any committer may cherry-pick any commit from blead to maint-5.12 if
they send mail to perl5-porters announcing their intent to cherry-pick
a specific commit along with a rationale for doing so and at least two
other committers respond to the list giving their assent. (This policy
applies to current and former pumpkings, as well as other committers.)
Perl 5.12.x release schedule:
It's fairly common to find minor but annoying issues in a new major
release of Perl just a couple days after we ship a .0 release.
It is my intent to release Perl 5.12.1 roughly one month after we
release 5.12.0. This will mean freezing for 5.12.1-RC1 roughly 3 weeks
after we release 5.12.0. This, obviously, isn't much time, but with the
new policies on what goes into maint and allowing porters to share the
cherry-picking load, it's my hope and belief that it's not an
implausible task.
It is my intent that 5.12.2, 5.12.3 and 5.12.4 will follow over the
course of the next year. I plan to freeze blead for the release of
Perl 5.14.0 early next spring.
Depending on what's reported in the wake of a given release, this
schedule may change.
Best,
Jesse
Thread Next