On 8/11/17, Michael Niedermayer <mich...@niedermayer.cc> wrote: > On Thu, Aug 10, 2017 at 04:15:55PM +0200, Nicolas George wrote: >> Le tridi 23 thermidor, an CCXXV, Michael Niedermayer a écrit : >> > Please limit the notes in filters.texi and Changelog to the filters and >> > options you intend to change. >> >> That would defeat the purpose. Doubly so: >> >> - Being free to change the options as need requires. That means any >> filter and any option. Not all, not many, but any. >> >> - Having a rule that is simple to remember instead of a long list. >> >> Please bring new arguments to the discussion if you want to continue it. > > well > First, I dont think a single developer should declare a whole class of > interfaces spaning the areas other developers work on unstable against > one or more objections from them. Or if one has that right then everyone > else should as well. > > I maintain several filters and clearly stated that this doc-text does not > apply to them. None of them would benefit from breaking the > order or inserting options in the middle. > In fact with a unstable order there is no benefit from adding options > in the middle, noone could reliably use the new order. > > as in if you link to libavfilter 99.123 you can write a:b:c , if you > link to libavfilter 99.124 you can write a:c:b. Update your distro > package and it could change in otherwise unchanged applications. > > and none of this in the example above is neccesarily a syntax error > and gives an error message. the different order could just give > different results. thats bad design > > I like to re iterate, i do not agree to declaring the option order > of the filters i maintain as unstable. > > Even if we could reorder them without disadvantages, > there is no benefit in doing so. > > Its trivial to change your docs/changeog patch to avoid my concern, and > its trivial to change MAINTAINERs as well if people value declaring the > interfaces as unstable more than a maintainer who fanatically insist on > maintaining a stable interface in the filters he maintains. > > Also there is no long list, just a entry in the changelog and in the > documentation of the specific filter which was changed. > I think we both agree that this is a rare event. And i would argue > it is NOT a event specific to the shorthand interface. Am i not > correct that you would similarly change the named interface if a > cleanup you do benefits from it ?
What about keeping old options intact? _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
