On 11/09/16 18:57, Clément Bœsch wrote:
I think we disagree, because no user of a working setup will ever read the
documentation just to check for deprecated tools. Having the warning at
runtime is the most efficient way to reach out a maximum of users as soon
as possible so they have time to migrate their setup. A bit like
deprecation warning in API at build time.
You are trying to cater to the wrong people. There sure are people who don't
read the documentation, but who are they? ... There are those who don't upgrade
and consequently have no need to read NEWS or the documentation - them you don't
need to care for obviously. They will read about it in the documentation when
the time comes for them to upgrade. Then there are those who expect everything
to stay the same only to learn the hard way of a change - them you don't need to
care for and they also won't appreciate it when you do. Then there are those who
don't read the output of ffserver, because of how they run it (i.e. from a
script as a daemon) and who only occasionally check their logs - they either
belong to the group of "hard learners" or they have read the documentation. Your
point really only makes sense if you wanted to care for people who care for
documentation, which means you should properly document it.
People who need to migrate have nothing to migrate to - they will try to use the
existing releases as long as it works for them. They may be seeing the printed
message for a lot longer than you would want them to. They won't find anything
good about the loss of ffserver or having to find a replacement. They won't like
the message, only a few will ever be actually grateful for it, but even they
will not like it or care for it after seeing it for the hundredth time.
Sven
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
