develooper Front page | perl.perl5.porters | Postings from July 2016

Re: Indented here docs?

Thread Previous | Thread Next
Sawyer X
July 2, 2016 20:50
Re: Indented here docs?
Message ID:

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.)

perlpolicy says:

    Experimental features must be experimental in two stable releases
before being
    marked non-experimental.  Experimental features will only have their
    experimental status revoked when they no longer have any
design-changing bugs
    open against them and when they have remained unchanged in behavior
for the
    entire length of a development cycle.  In other words, a feature
present in
    v5.20.0 may be marked no longer experimental in v5.22.0 if and only
if its
    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.


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