On Mon, Feb 13, 2012 at 10:42 AM, Brian Matherly <[email protected]> wrote: >>> By my count, we could be supporting 10 to 12 different variations >>> (depending on how you count the older ones): > >>> * FFmpeg HEAD >>> * FFmpeg 0.10 "Freedom" >>> * FFmpeg 0.9.1 "Harmony" >>> * FFmpeg 0.8.10 "Love" >>> * FFmpeg 0.7.11 "Peace" >>> * FFmpeg 0.6.5 "Works with HTML5" >>> * FFmpeg 0.5.8 "half-way to world domination A.K.A. the belligerent blue >>> bike shed" >>> * Libav HEAD >>> * Libav 0.8 "Forbidden Fruit" >>> * Libav 0.7.4 "The Big Bump" >>> * Libav 0.6.5 "Works with HTML5" (same as FFmpeg?) >>> * Libav 0.5.7 "half-way to world domination A.K.A. the belligerent blue >>> bike shed" (same as FFmpeg?) >>> >>> If we want to chases all of these variations, then I think some automation >>> is in order. >> >>If you recall, for the longest time, releases were far and few >>between, and there was only ffmpeg. In that mode, all I needed to do >>is update things as the head creeps along being careful to not break >>the older code. That combined with user feedback and testing against >>distro packages on a few different personal systems and sometimes a >>couple of VMs seemed sufficient. The releases are still rather >>superficial as far as how it affects that mode of operation. However, >>the forking and rate of change has become a problem. >> >>Thanks to you we have begun some automation now. However, I am not >>certain how much you should expand it. You could reduce the frequency >>to daily, supply an argument to the script to use a release tarball, >>and cache the downloaded tarball. Thoughts? > > > This seems reasonable to me: > * Modify the build-melt.sh script to allow the specification of a repository > and branch for ffmpeg
It can already take a config file, so we just need to make a separate config file for each configuration, but we will need a modification to handle ffmpeg.org vs. libav.org git URLs and directory names. > * Set up a script that runs build-melt.sh against all the head of all the > repository/branch combinations above > * For each repository/branch, run a set of simple tests > * Automatically run the tests every night > > It seems to me that if we test against the head of each branch, then we don't > necessarily have to test against each individual tarball release that ever > came from that branch. Surely they wouldn't break API compatibility in a > branch. > OK, reasonable assumption > It might be nice to grep the output of the build process for deprecation > warnings and call that a failed test. > no, thank you. Deprecation is not an error, and it will be too much work to keep on top of it as I tend to batch up work on those things. Also, ffmpeg and libav do not always use the same version for changes, and there are time delays for when things get merged into each other. Plus, there are different sets of deprecation warnings for the different version branches, and it can be difficult to figure out the correct version to use. -- +-DRD-+ ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Mlt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mlt-devel
