[FFmpeg-devel] release feedback

[Vitor Sessak]

Diego Biurrun wrote:
> On Sun, Mar 15, 2009 at 02:21:15PM +0000, Robert Swain wrote:
>> On 15/3/09 11:56, Diego Biurrun wrote:
>>> On Sat, Mar 14, 2009 at 09:16:32PM +0000, Robert Swain wrote:
>>>>> One question that remains is whether we should repeat this regularly or
>>>>> at all.  Given the positive feedback, I believe we should institute a
>>>>> regular release schedule.  I envision time-based releases every 3 or 6
>>>>> months.  After some thought, 6 months sounds preferable.  It is less
>>>>> disruptive to the development process and a schedule that seem to work
>>>>> well in a lot of other FOSS projects.
>>>> I would like 3-monthly releases.
>>> Why?
>> FFmpeg development is very rapid. If we space releases too sparsely, we 
>> (the developers) will have less faith in releases and this will transfer 
>> into telling users to use trunk more due to the previous release being 
>> outdated. I think this devalues releases.
> 
> Most people seem to survive a few months without updating their software.
> I don't think it's a problem to tell them to wait some time or use trunk
> as long as the wait schedule is dependable.
> 
>> Many popular distributions have ~6 month release cycles that are not 
>> synchronised. Using the same level of granularity, I think it would be 
>> quite easy for one of our releases to miss their package freeze windows. 
>> As a lot of packages depend on FFmpeg, this may have a significant 
>> impact on the functionality, bugs and so on that are apparent in a wide 
>> variety of packaged software. Maybe this is a non-issue, I'm not sure.
> 
> We could pick some distro and synchronize with them if need be.
> 
>> My gut tells me that 6 months is a big gap and 3 months less so while 
>> still being a reasonable amount of time for a lot of changes to be made 
>> in trunk.
> 
> I think going from no releases to two releases per year is a start.
> Let's not get carried away too much, getting another release out in
> half a year will be difficult enough.
> 
>> We should really keep on top of documentation as we go along and I'm
>> sure you'll agree with this Diego. After efforts from Diego, Justin
>> and others just before the release, this should also consume less time
>> in future.
> 
> Yes, please help keeping stuff synchronized.  Manually getting it
> current was a thankless chore.
> 
>>>> [.. long description ..]
>>>>   From what I perceive, this is actually what we did for 0.5 as we had to
>>>> back out a few changes that had been made in trunk at the point at which
>>>> we branched to make the code base feasibly releasable.
>>> So in summary this means no process changes.  Pick a revision to base
>>> releases on and identify regressions.
>> Do you think the potential release process policy of requesting feedback 
>> from maintainers as to the status of their code as well as looking at 
>> our regressions suites is reasonable? I think it gives us a better base 
>> for quality control considering the limited scope of our regressions 
>> tests for the moment.
> 
> If we have a fixed timeframe, maintainers could work towards getting
> their code into release-ready shape in a timely fashion.

I like the idea of a fixed timeframe. I also think it might be a good 
idea to release unstable versions in the following way:

1- Release stable version
2- Make all the necessary API breakage
3- Release unstable version

The idea is that people using libav* (or the ffmpeg binary) could know 
when and with which version to test their application work with the next 
version when it gets released. Concretely, I think that there was some 
considerable API changes in the last few days (vhook removal et all) and 
now would be a nice time to release a unstable version. And them try not 
to break API until next release.

And yes, we should point in the main page that the main "feature" of the 
unstable version in comparison with the stable one is breaking API, 
people wanting the newest features should use SVN...

-Vitor

PS: an alternate (and simpler) way to implement my suggestion is just 
make a tarball of SVN every time we bumb the major version of some lav* 
and call it a unstable release