[FFmpeg-devel] [PATCH] doc/filters: document the unstability of the shorthand options notation.

[Michael Niedermayer]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20170808/84d2758b/attachment.sig>