Fri Jan 30 10:44:11 CET 2009
2009/1/30 Jai Menon <jmenon86 at gmail.com>:
> On Fri, Jan 30, 2009 at 2:55 PM, Nicolas George
> <nicolas.george at normalesup.org> wrote:
>> Le septidi 7 pluvi?se, an CCXVII, Diego Biurrun a ?crit :
>>> Just think about it, we throw out a tarball and then we can go wild
>> Does that mean that, one year from now, people still using that tarball
>> instead of the SVN head will be welcome on the mailing-lists and that
>> bugfixes will be backported?
> This is similar to questions I asked myself when I thought about
> how exactly the release will be managed. Maybe the release manager
> would like to comment on how the release branch will be maintained over
> time. Backporting relevant bugfixes is trivial but somebody will have
> to do the work.
I see this working in two ways:
- We disregard traditional release strategy and make frequent releases
in a similar fashion to the people over at Wine (though they seem to
have stable and development branches...) and if we come across
security issues, we simply fix them and make a release shortly after
containing the security fixes. I don't think this works immensely well
as it forces people to possibly upgrade the API and so on for the sake
of a security fix.
- We backport security fixes, document them and release fixed
tarballs. How long do we backport security fixes to a release? Until
the next release? What if the next release has API/ABI changes?
More information about the ffmpeg-devel