On 12/11/2017 11:28 AM, Hendrik Leppkes wrote:
> On Mon, Dec 11, 2017 at 2:22 PM, Paul B Mahol <one...@gmail.com> wrote:
>> On 12/11/17, Hendrik Leppkes <h.lepp...@gmail.com> wrote:
>>> On Mon, Dec 11, 2017 at 12:07 PM, Paul B Mahol <one...@gmail.com> wrote:
>>>>> Fine, but it's inevitable that the encoder supports the J formats still
>>>>> for a while.
>>>> Why are you all dismissive about this?
>>> Because we have an established way to remove things like this, and
>>> that doesn't happen over night.
>>> Its not ok for stuff to stop working without a replacement in place
>>> for a sufficient time before that, so people can migrate.
>>> First, implement replacement and add visible deprecation messages -
>>> and then wait the established deprecation period before actually
>>> removing it.
>> Bullshit, J formats are deprecated for ages.
> A deprecation is only meaningful if there is actually a replacement
> you can use - which did not exist yet.
> Want to encode jpeg right now? Have to use J format. No way around
> that. And many more of such cases.
> As such, you can't just make the J format non-functional over night.
> Thats not going to fly.

And how will we get users to migrate? We have printed a "deprecated,
don't use" message that has been ignored by absolutely everyone for a
whole decade. What could we do or add now that will actually get people
to read and pay attention to a "for real now guise" warning?

The current warning gives instructions about the supposed replacement,
yet it doesn't work. Even if it suddenly starts to work, who the hell is
going to try it again after it failed time and time again for like
twenty different releases?

> Either do it properly, or don't do it at all.

Someone finally started to work on getting rid of one the oldest, most
annoying hacks in the codebase. Help or suggestions in how to implement
said compatibility layer and deprecation period would be much better
than this.
ffmpeg-devel mailing list

Reply via email to