Front page | perl.perl5.porters |
Postings from December 2017
Seems like an experimental feature that has been allowed to remain for many years becomes a defacto feature... sort of like a British public footpath. So remove the experimental designation and reduce confusion/friction. If you want a smart switch feature, you almost have to use orthogonal keywords. If the value is good enough the new feature will succeed over time. John Alvord On Fri, Dec 29, 2017 at 9:58 AM Zefram <zefram@fysh.org> wrote: > Leon Timmermans wrote: > >I'm not aware of any other major open source language that quite dumps new > >features on their users like we do. > > We've got feature flags and experimental status to manage this. We mostly > stopped just dumping new features onto users years ago. > > [smartmatch] > > Late in that discussion changes were introduces > >with compatibility consequences that weren't immediately recognized as > >such; > > What specifically are you referring to here? I don't see anything > matching that description. The only compatibility consequence that > I see that was not immediately spotted was the issue of the "switch" > feature being on by default for some existing version bundles, which > interacts with the changes in keywords, but these changes didn't really > start "late in that discussion". I also doubt that thinking about it in > advance would have spotted that issue. It certainly wouldn't have made > a difference to the resolution: if the changes hadn't been reverted, > I was going to tweak the feature flag setup, in exactly the same manner > that I would have if I'd been aware of the issue in advance. > > >Only after that one can actually design the feature. > ... > >After that, "Someone with time on their hands" can actually implement it > > I reject the notion that a waterfall process is a good approach in general > or that enforcing such a process would solve problems. Issues often arise > during development that were not apparent before touching any code, and > spending longer before touching any code doesn't prevent that happening. > If you enforce the sequential requirements-design-implementation process > then that just means that you can't address these problems when they > inevitably arise. > > -zefram >Thread Previous | Thread Next