Gaining Momentum

Don’t look now, but the idea of making a formal FFmpeg release in the very near future is gaining traction over on the FFmpeg-devel list. There is a determined and growing team of individuals committed to this goal in the near future. To that end, there is even a Wiki page listing the steps that need to occur leading up to a release.

There is some debate about what kind of release schedule we should commit to. Some take the stance that we should follow the model that Wine apparently follows by releasing every 2 weeks. Really, every new weeks? I had never heard of that before. It strikes me as a bit severe. I personally would like to see a little more time between releases, but see them often enough that we get really good at it, and it becomes part of our shared community mindset.

After all, there are a few projects out there that depend on FFmpeg.

I admit, whenever I get to thinking about an FFmpeg release, I get a little nervous about the ensuing discussion. Not the discussion about whether or not a release should happen; that’s a foregone conclusion because it will happen. No, the item that makes me lose sleep is the biggest bikeshed hue discussion of them all — how should we version the upcoming release of FFmpeg? I don’t think I even want to get involved in that one.

3 thoughts on “Gaining Momentum

  1. Peter

    I guess that’s why more and more projects are moving to release numbers derived from the release date (E.G. 2009.01) – That pretty much kills all emotional significance of the numerical value of the release (E.G. the old pre 1.0 is unstable) and at the same time provide usable information (How old is this release)

  2. yoshi314

    i agree about versioning. gentoo versions ffmpeg as 0.4.9_pYYYYMMDD : http://packages.gentoo.org/package/media-video/ffmpeg. i think it’s a good idea, and it could stay this way. the problem would be when to bump the front number ;-)

    if there are to be official releases, they should be frequent, because there would be less security/stability fixes that would require backporting – that means less work for maintainers.

    on the other hand, most (actively developed) projects are probably accustomed to following ffmpeg svn checkouts, so there is no real problem there.

    i think new version should come when something gets really changed in ffmpeg internals and suddenly breaks compatibility with projects using current ffmpeg.

  3. Steve Dibb

    For Gentoo, we just do mplayer with the SVN release tacked onto the last time they actually released a version (1.0_rc2, in this case).

    But I like the date one ffmpeg uses as well.

Comments are closed.