Front page | perl.perl5.porters |
Postings from July 2016
Re: Indented here docs?
From: Sawyer X
July 2, 2016 20:50
Re: Indented here docs?
Message ID: email@example.com
On 07/02/2016 10:01 PM, Paul Johnson wrote:
> On Fri, Jul 01, 2016 at 10:38:47PM -0700, Father Chrysostomos wrote:
>> We currently have a policy that new features go through an
>> experimental period for a while. I think that would have to apply to
>> this feature, too. And then you can use <<- without having to worry
>> (for now) about breaking existing syntax.
> I know what perlpolicy says, and I know why it says it, but what we are
> saying now is that this feature would be experimental in 5.26 and 5.28,
> and would then be fully available in 5.30. That's 2019.
> Surely we can do better than that for a reasonably simple, constrained
> and useful feature?
Father Chrysostomos is correct. We need to provide this as experimental
feature at first. This sucks when we really want something, but it
allows Matthew and all of us room to possibly change an oversight or a
bug. Imagine we merge it and, only once someone tries to use it, we find
an edge case which requires making a change that is possibly
incompatible or might cause other breakage of which we haven't thought.
Ugh. Not releasing as experimental forces us (in many case a single
developer or very few developers) to get it right on the first try.
(Sorry for harping on this for an entire paragraph.)
Experimental features must be experimental in two stable releases
marked non-experimental. Experimental features will only have their
experimental status revoked when they no longer have any
open against them and when they have remained unchanged in behavior
entire length of a development cycle. In other words, a feature
v5.20.0 may be marked no longer experimental in v5.22.0 if and only
behavior is unchanged throughout all of v5.21.
-- perlpolicy in blead.
The purpose is stated as features that "[...] no longer have any
design-changing bugs open against them" (meaning, it seems to be fine
and good) and "remained unchanged in behavior for the entire length of a
development cycle" (meaning we fully vetted them for an entire release
with no change).
Perhaps we should consider a change to the policy for changes that were
added to a release and had neither design-changing bugs open against
them, nor were changed for the entire development cycle of the next
release. This means that if it was added in 5.25.x, made experimentally
available in 5.26.0, and that during 5.27.x, it had no changes, it might
be possible to mark it as stable and available for 5.28. Does that make
Do we believe this situation is likely to happen? Probably not with the
features we would really be worried about that justify having a
two-release experimentation cycle.