Hi On Tue, Aug 08, 2017 at 11:20:31AM +0200, Nicolas George wrote: > Le decadi 20 thermidor, an CCXXV, Marton Balint a écrit : > > That is why I believe a breaking change such as the overlay filter option > > order change should be mentioned in the Changelog. > > Yes, you are completely right. > > Also, let me clarify something: pushing this documentation change does > not mean I intend to break the order of options at a whim. Not at all. > In practice, nothing will change, almost. But it means that if there is > a strong need to change the order, we can consider it comfortably, and > without wasting valuable developer time with compatibility workarounds. >
> Regarding the exact rule: we could document that there are some options > we do not intend to touch (essential options), but what would be the > point, really? Iam a bit puzzled that you really seem not to see what damage this would do. All scripts, all applications using libavfilter must be changed to use the named arguments if the shorthand is not stable. all examples will need to be changed too or the examples would show syntax that is non stable. Examples do not target scripts or end users specifically so we may end up with duplication and extra complexity. If you dislike C language lawyerng over undefined behavior, this is exactly the same but worse. If we say it may be unstable even if its very very unlikely everyone who takes stability serious will change their code, tutorials, docs and examples. This will also add alot of confusion to teh end user as suddenly the consistent use of shorthand is replaced by some documents and tutorials using the shorthand in accordance of it being ok-ish and some take the strict approuch and remove all shorthand use. Extra explanations to clarify "why" added, cause the user to waste more time to learn about "why" The whole would add a reason to avoid libavfilter and use an alternative If i "as a user" have the choice between 2 libs, one with a long term stable interface and gurantee by its developers that it will stay stable and a lib that in practice broke its interface and added a declaration that parts which where stable before are not anymore and unspecified future changes are possible". I would favor he lib with stable interface. And loss of users also always means a loss of potential developers, as users of a lib is a source of developers of that lib. Loss of some users is bad on its own of course ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already.
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
