[Ffmpeg-devel] Re: Advocating periodic releases

[Clarke, Trevor]

> With all due respect I would find it very confusing to have releases
in 
> the same repository as development. That may be how you like to do 
> things and you have every right to that opinion but my professional 
> configuration management experience screams no!!!. I have no objection

> in principle to the use of the svn *server* at mplayerhq, but release 
> are not development and in a proper environment developers do not have

> privileges to check things into the release tree.
>
>  Rather, they submit release candidate code to the CM team and if it 
> passes whatever QA/test then it gets checked in as a part of a release

> candidate or development and released to see if there are any issues
for 
> which we don't have tests (and for the porters to compile on various 
> environments; it is, for example, not simple for me to get ahold of a 
> Mac OS X machine and at that its a Powerbook not an intel Mac....and 
> forget about BeOS AIX IRIX ....I don't have current MS Visual Studio 
> either and t some point even if i have access to build it'd be nice to

> have someone else looking at e.g. cygwin). any issues that come up we 
> try for simple fixes otherwise we  document the issue in the release 
> notes as a known bug and possibly revise the test suite so that future

> releases will not pass with the bug. Until we have a fix we don't 
> include the test obviously.

We have release and dev in the same repo here and we have a very strict
CM system. We always branch for new work and each branch gets code
reviewed by at least two other developers. Once that's accepted (and it
passes regression tests) the developer merges into a development trunk.
When it's time for a release, the CM person tags the trunk to a release
tag, performs addition tests, builds installers, etc. These tags are
read-only for all but the CM person (subversion allows fine grained
read-only/read-write/no-access per user (and for anonymous) on all
directories in a repo) Hasn't failed us yet and we have the benefit of
easily accessing all revision history for the release tags without going
to a separate repository.
--------------------
Trevor R.H. Clarke
tclarke at ball.com
Ball Aerospace & Technologies Corp