David Golden <xdaveg@gmail.com> wrote: :I expect that 99.9%+ of Perl users do not build dev releases (much :less test code on them), as much as we encourage them to. Thus, I :don't expect anyone to react to a deprecation warning until the stable :release in which deprecation warnings start. (Thankfully, we have :Andreas who regularly smokes blead because that's most of the "live :code" smoking we get.) : :So while I don't like "risky" code late in the dev cycle (by which I :mean things that are complex and might have surprising bugs revealed :in testing), I don't see any reason why deprecations can't be :introduced right up to the code freeze, since the only point it really :affects most users is when the stable release is done. I consider this deprecation risky: it may break things by being misimplemented, or it may break things by introducing new warnings deep in code that doesn't expect it. Further, I consider there is a non-zero probability that once we try it we may find that the practice we wish to deprecate is so widespread that we reconsider our approach. In particular, this isn't some practice that was previously dubious or "always broken" - as far as I know, the norm and received wisdom has always been "don't escape what doesn't require it". Attempting this at the start of a cycle would give us the space we need to discover whether it's a really bad idea. HugoThread Previous | Thread Next