[FFmpeg-devel] [PATCH] web/index: add news entry for release 3.3

James Almer jamrial at gmail.com
Sat Apr 15 02:48:55 EEST 2017


On 4/14/2017 8:32 PM, Michael Niedermayer wrote:
> On Fri, Apr 14, 2017 at 04:07:41PM -0400, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Fri, Apr 14, 2017 at 4:24 AM, Michael Niedermayer <michael at niedermayer.cc
>>> wrote:
>>
>>> On Thu, Apr 13, 2017 at 09:00:33PM +0100, Rostislav Pehlivanov wrote:
>>>> +    We strongly recommend users, distributors, and system integrators to
>>>> +    upgrade unless they use current git master.
>>>
>>> as some developers had concerns about the release in relation to
>>> merges prior to it, iam not sure we should recommand that or not.
>>>
>>> We could also wait with adding such recommandition and for example
>>> add it for 3.3.1 when no major issues are reported on release/3.3
>>
>>
>> It's unusual to make a release if we're not sure users should upgrade to it?
> 
> iam not sure i understand what you are trying to say?
> but ill try to awnser anyway
> 
> I dont think its unusual that after a large number of changes or a long
> time since the last release theres higher uncertanity in the code state.
> 
> Nor is it unusual that one doesnt suggest everyone to upgrade to a
> "dot zero" release but waits for .1, for example ubuntu does that AFAIK
> 
> Iam not sure what the team prefers, how can i be sure without asking?
> and thats what i did above, i asked

IMO, since the "we strongly recommend" line has been a constant in all
releases, removing it now will (for those that notice it) rise quite a
few red flags and make people come to the conclusion they should
probably skip it altogether.
If we expect people to use it and hopefully report any issues with it,
we shouldn't do something that will scare them away.

And really, the tree wasn't any more "unstable" when we branched it
for 3.3 than how it had been when we branched previous releases. All
new release branches featured merges up to some arbitrary point.
It's even been two weeks since the branch was cut, and no outstanding
issues were found even in master, so lets try to not start spreading
uncertainty.


More information about the ffmpeg-devel mailing list