Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > This and many other discussions on-list basically come down to: > > 1. Someone wants to change X. > 2. This would have user impact Y. > 3. We have no way to quantify Y. > 4. X doesn't happen out of fear of unquantifiable Y. You forgot the step 0. You need to answer two questions: "Is changing X necessary?" and "Does that necessity outweigh the inconvenience caused to existing users by the deprecation flow?" You need to answer yes to both before you even consider going into the later steps. Once that happens,... > It seems to me that a way out of this that would make everyone happy > is to go through some deprecation cycle through several releases with > X where: > > 1. We detect that you're using X, and warn that it's a candidate for deprecation > 2. In another release, we turn off the feature by default, threatening > that it's going to go away forever unless someone pipes up (this is > what we did with rsync:// accidentally) > 3. In another release, If you turned on the feature after #2 we emit a > noisy warning every time it's used, saying "it'll really be removed in > $release+1" ... the deprecation practice is very well established around here. In this case, however, we haven't even seen the first question "Is it needed?" answered "yes", let alone "Is it needed enough?".