On Mon, 11 Dec 2017 11:36:52 -0300
James Almer <jamr...@gmail.com> wrote:

> 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?

Well, whatever we do, the first step is adding a replacement mechanism
that actually works, without breaking J formats.

That includes not removing the J formats from libswscale or the jpeg

Then we need to adjust the warning message (maybe add another one for
specifically for the jpeg encoder?), and note the change in APIchanges.

2 years later we drop the J formats and all compatibility code.

> > 
> > 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