[Ffmpeg-devel] 0.4.9-pre2?

[Jacob Meuser]

On Wed, Jun 29, 2005 at 10:17:20AM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Wednesday 29 June 2005 05:54, Jacob Meuser wrote:
> [...]
> > > 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.
> 
> its not only testing thats needed but also someone who is willing to fix the 
> found issues, if the later is not avilable in a large enough amount the extra 
> testing becomes less usefull unless of course you delay the release for 
> months stop all development and force the few developers around to fix bugs 
> they dont care about but thats not something i would like to see happening

yes.  that's why I mentioned that a lot of people are using CVS
and there don't seem to be (m)any major issues.  so, the testing
is already happening.  I was thinking more along the lines of
fixing possible issues with compilation on various platforms.

> 
> >
> > > 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".
> 
> well, i disagree, its sure a bad idea to do some big or risky changes shortly 
> before a release but a "you may not change anything except fixing release 
> critical bugs" is silly it tries to fix a problem which isnt real, if someone 
> disagrees i would like to hear some examples of non bugfix changes shortly 
> before a release which broke things
> one possibility would be to fork and apply a strict no non bugfix changes rule 
> to that and iam happy with this if whoever takes care of the release wants it 
> but i doubt its a good idea

I agree.  I was thinking of like 7-10 days total "slow down" time.  I
don't think that is all that long.  also, it doesn't mean that developers
need to stop what they are working on, just don't commit big changes in
that time.

> >
> > > 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".
> 
> ok

-- 
<jakemsr at jakemsr.com>