Front page | perl.perl5.porters |
Postings from December 2017
On Sat, Dec 30 2017, Father Chrysostomos jotted:
> Avar wrote:
>> I think in the future it makes sense to hold
>> ourselves to reviewing these features once they've been unchanged in say
>> 2 or 3 releases, and for the policy to say that experimental features
>> unchanged in 3 development cycles must either be promoted to
>> non-experimental, removed entirely, or have their semantics changed in
>> major ways.
>
> I don't think it makes sense. If a feature is significantly flawed
> (and experimental) due to lack of tuits (e.g., refaliasing), do
> we have to make meaningless design changes to it to avoid having
> it yanked?
Not meaningless design changes, but to have some sort of schedule
(preferably enforced by code, i.e. as soon as we begun 5.25 we start to
warn/die) giving these experimental features an explicit expiry date.
The way perlpolicy is worded now, we could introduce an "experimental"
feature and not change its semantics for 20 years, and still call it
"experimental". That's absurd.
Consider the situation we're now in. We're about to release 5.28 and
we've chickened out on changing a supposedly "experimental" feature
mainly because it breaks stuff on CPAN.
This is the use it or lose it moment, either we change the semantics, or
we have to recognize that the "experimental" status perlpolicy talks
about doesn't exist at all, we're back to the pre-Jesse days of "change
perl and if people use it the semantics stay forever".
I'm not saying we have to take Zefram's patches as-is, but we should at
least change to something so that unless you specify:
no about::to::deprecate "smartmatch";
We'll just die when we see given/when, to prepare people for "yes we're
*really* about to change this and we mean it".
> I do not believe there is anything in the process that could change in
> such a way as to help. Some seem to be treating this situation as a
> disaster that could have been avoided, not realising that the disaster
> *was* avoided, *precisely* because of the process we currently have,
> which is working. Nothing has been dumped on users in a stable
> release yet. I would call that success.
As noted above, this is the opposite of success if the goal is "we
should be able to change/remove experimental stuff".
Thread Previous
|
Thread Next