[FFmpeg-devel] release

[Alexandre FERRIEUX - FT/RD/SIRP/ASF/SOFTL]

Robert Swain wrote:
> 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?
> 


My $0.02 from a different project: Tcl.

There we fork a branch / major release only for compatibility breakage.
At any given time we have only two or three such branches: the current 
(trunk) and N-1 and possibly N-2 major releases. Inside each branch we 
have the normal flow, with HEAD providing no guarantee but tagging from 
time to time, yielding a minor release. We backport whatever can be 
(only bugfixes) and makes sense (i.e. non-negligible demand). And the 
tagging occurs independently (e.g. when a sufficient number of fixes 
have been accumulated for branches, or when a Whoa ! new feature is in 
the trunk).

This way, users can:

    - stick to a version and never change

    - stick to a branch (major release) because the compatibility 
breakage locks them, but still get fixes (in the form of minor releases) 
for the duration of 2 major releases (which in our case means years)

    - keep up with the wave and use the latest minor release, adapting 
to compatibility breakages when they come up, but not suffering from 
random  "won't-compile-midnight-commit".

    - surf on the bleeding edge with a 1-minute crontab saying 'svn up'

The whole works fairly well, in being very conservative (a compatibility 
breakage has to be throroughly pondered) without empeding innovation, 
and keeping the backport effort within acceptable boundaries.

FWIW :-)

-Alex