[Ffmpeg-devel] 0.4.9-pre2?

Michael Niedermayer michaelni
Wed Jun 29 10:17:20 CEST 2005


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


>
> > 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

>
> > 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

[...]

-- 
Michael





More information about the ffmpeg-devel mailing list