[Ffmpeg-devel] 0.4.9-pre2?

[Jacob Meuser]

On Tue, Jun 28, 2005 at 08:59:38PM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Tuesday 28 June 2005 20:28, Diego Biurrun wrote:
> > On Mon, Jun 27, 2005 at 09:00:44PM +0200, Michael Niedermayer wrote:
> > > On Monday 27 June 2005 20:35, Robert Lippmann wrote:
> > > > hi all,
> > > >
> > > > just my $.02, but judging from the number/type of cvs commits, maybe a
> > > > release is in order?
> > > >
> > > > this can allow distro maintainers/dependent projects to have a
> > > > relatively stable, fixed point to link against.
> > >
> > > does anyone of the ffmpeg developers want to take care of that release,
> > > if no then well no release ...
> >
> > What exactly does an FFmpeg release consist of?  "Just" a CVS snapshot
> > that is tarred up and announced?  Or a series of tests and a
> > stabilization period and whatnot?
> 
> well, heres a suggested list (comments welcome)
> 1. announce it 1 week ahead on the mailinglist so that whoever wants to see 
> something fixed before the release can fix it

might not hurt to take the latest snapshot, rename it to "beta",
tell people this will be the next release, except for fixes,
and ask for heavy testing.  "If you don't test, you can't
complain ...".  the buzzword thing actually does get people
motivated.

> 2. update Changelog / INSTALL / README files if needed
> 3. update version information in various files
> 4. if there are any big problems here or later delay or return to a previous 
> step
> 5. take a cvs checkout

hmmm.  IMO, it would be good to slow down (more or less stop, except
for fixing known issues) commits to the sources while the beta is
"in testing".

> 6. make a tarball
> 7. check compilation (follow INSTALL) & regression tests & make install
> 8. check against some actual files, not many just 1 or 2 for each container 
> type (if something doesnt work try the previous release and if it got worse 
> judge if its important enough to fix before the release)
> 9. upload the tarball as "release candidate" and announce it on the 
> mailinglist
> *wait 24h*

I would say 72h, depending on how much the "beta" got tested.  not
everyone who would be interested in a "formal release" would be able
to check things "right away".

> 10. if no big issues here then make the real announcement & upload

I guess it really depends on whether you want to slow down commits.

that being said, it seems a lot of people are using CVS anyway, and
there don't seem to be too many issues with the current code.  so
you could probably just do steps 1, 2 & 3 and just rename a snapshot
as the release.  as a package maintainer, it doesn't really matter
so much if there are small bugs.  package maintainers should know
how to get patches from CVS.  what matters is knowing what versions
of which packages are compatible, which is a lot easier if there is
an actual release.  having a release also usually makes it easier
for other projects, because they can say "Use FFmpeg-0.4.9-2."
instead of, "Well, it worked with FFmpeg CVS from 2005-06-28.  You
can get that from the FFmpeg cvs repo using 'cvs -D ...'."

-- 
<jakemsr at jakemsr.com>