[Ffmpeg-devel] Re: Creating releases

[Axel Thimm]

On Sat, Apr 14, 2007 at 02:00:56PM +0200, Michael Niedermayer wrote:
> also are you planning to extensively test the release against the mphq
> samples archive and compare the against the previous release to detect
> regressions?

I would conder that more part of the development QA cycle of adding/modifying
code. If this can be automated I could have some kind of continuous
integration tests of this. But I wouldn't define it as part of the
release process.

> test compilation and regression tests on several different architectures?
> test make install?

Of course. That's the very least that needs to be tested.

> write uptodate README/INSTALL files?
> update the changelog? 

The changelog looks like it's being kept up to date. Or do you mean
adding the next version's tag?

I envision the release process as follows:

o development considers revision XYZ a good release candidate (XYZ
  need not be the latest revision in the trunk, perhaps there is some
  new, unfinished code that entered the trunk), the release slave is
  pinged.
o The release slave creates a copy of revision XYZ under /branches.
o He reviews the code for any mismatching version strings, forgotten
  changelog entries, READMEs etc.
o He tests the builds out of this branch
o If everything looks fine, he will make a release candidate (under
  /tags and as tarballs) for others to take a peek.
o If something is broken, he either fixes it, or escalates it to the
  developers, otherwise he releases the release candiate as a golden
  release.

If all go well, the developers have only spent some time on agreeing
whether XYZ is a good revision for releasing. If something pops up
during the release process the developers may be asked for
feedback.

The first releases will probably occupy more developer time, as they
will be monitoring whether the releasing works or is going to add them
more pain than gain. Once it is rolling it and no major bugs are
unearthed during the release process the developers' time resources
will be untouched.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070414/32178a40/attachment.pgp>