[FFmpeg-devel] [PATCH] web: Remove recommandition to upgrade to 3.1

Michael Niedermayer michael at niedermayer.cc
Thu Jun 30 15:17:10 CEST 2016


On Thu, Jun 30, 2016 at 08:21:07AM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Thu, Jun 30, 2016 at 8:16 AM, Michael Niedermayer <michael at niedermayer.cc
> > wrote:
> 
> > On Thu, Jun 30, 2016 at 07:57:29AM -0400, Ronald S. Bultje wrote:
> > > Hi,
> > >
> > > On Thu, Jun 30, 2016 at 4:32 AM, Michael Niedermayer
> > <michael at niedermayer.cc
> > > > wrote:
> > >
> > > > On Wed, Jun 29, 2016 at 11:21:48PM -0300, James Almer wrote:
> > > > > On 6/29/2016 9:27 PM, Carl Eugen Hoyos wrote:
> > > > > > Ronald S. Bultje <rsbultje <at> gmail.com> writes:
> > > > > >
> > > > > >> For the record: there was some discussion related to this on IRC.
> > > > > >
> > > > > > Would you mind adding some relevant points here?
> > > > > > I was under the impression that this mailing list
> > > > > > is the main place for FFmpeg patch discussions, no?
> > > > > >
> > > > > > Carl Eugen
> > > > >
> > > > > [18:37:47] <@BBB> we should recommend that people upgrade to 3.1
> > > > tools-and-libs-at-the-same-time
> > > > > [18:45:42] <jamrial> and i agree with BBB, instead of removing the
> > > > recommendation, just make it clear that tools and libraries should
> > ideally
> > > > be updated at the same time and not mixed
> > > > > [18:48:11] <michaelni> jamrial, can you post a patch that changes
> > thre
> > > > recomandition to all libs/tools or changes the release notes ?
> > > > > [18:50:13] <jamrial> michaelni: alright
> > > > >
> > > >
> > > > > I'm fine with this patch or the one i sent. I'm not going to block
> > > > either.
> > > >
> > > > ok, i will wait until 24h have passed from the point of patch
> > > > submission, and in absence of objections on the ML, apply it
> > > > we should IMO pull this recomandition at least until 3.1.1
> > > > Iam also happy if others apply it or another solution sooner
> > >
> > >
> > > I prefer James' approach (recommending to update tools+libs together). I
> > > have two reasons:
> > > A) pulling a recommendation to update will be conceived as negative
> > press.
> > > Negative press is always bad. Media can always blow things out of
> > > proportion and all sort of crap will follow. I prefer to just keep this
> > > simple.
> >
> > do you realize that a distro upgrading to 3.1 will cause basically
> > almost every application that uses our libs to break ?
> > so far there are reports of kodi, mpv, chromium, ffplay and mlt
> > breaking. (breaking in the sense of not working at all IIRC)
> 
> 
> But won't any update of these apps to any future (same-major) version of
> ffmpeg break them?

if we break the used ABI it would break the user apps using it.
If we dont or the user apps stop using the ABI in question it wont
or if we bump major before the next release ...


> And isn't that because of a bug in the apps (use of
> private API)?

It is very likely a bug in the apps, still i dont think we should
recommand distros to upgrade without warning them about this

we didnt know all this when we made the release, now we know, i do
think we should update something, somewhere ...
sadly simply upgrading our tools and libs at the same time isnt
enough

of course maybe we can fully workaround this in 3.1.1 then this would
be a non issue ...


> And even if we worked around that bug in our libs (by making
> the fields public), wouldn't that still require us to move them and thus
> break ABI?

i dont think making them public (as in these fields a are now public)
would help much for the 3.0/3.1 issue but i might be missing something

making them public or moving them into an internal struct could be
part of a long term solution


> 
> So I don't see how keeping the update from 3.0 to 3.1 from users _alone_
> will help anything, other than buying time.

it would help distro maintainers to upgrade to 3.1.


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is what and why we do it that matters, not just one of them.
-------------- 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/20160630/b460b97c/attachment.sig>


More information about the ffmpeg-devel mailing list