Hi Sam, When we officially release the 1.0 version, this will mean that we freeze some features. After that, we can make bugfixes, but we should not break backward compatibility. So I wouldn't rush on this.
Beyond the compatibility questions, I'd really like the 1.0 to be stable and clean: we have many people who successfully use the SVN version but we should also think about people who need high stability. This point can be discussed but I think releases should be more than SVN snapshots "at okay times". I think we should start with a second beta release, as Romain suggested, because he introduced some pretty massive changes to dtools. Concerning what I intend to do, the big blockers are on my JIRA dashboard. Concerning stability, two open tickets regarding bugs in the source protocol; I have proposed patches (and committed some things, too) but I'm waiting for some feedback. The beta should be done after that, but it shouldn't take too long. Video is still not quite stable, and there's a good chance that only a little code (restoring and testing camlimages instead of sdlloader) could help, but that's not a top priority. Also I'd like VERY MUCH that we take the opportunity of releases to cleanup some code. In particular the src/io code is a mess -- there have been a few tickets about that for a LONG time. Those sources and operators should be made more uniform, for devs but also users (most outputs don't have start/stop commands, or fallible mode). Several I/O are not tested: did you get feedback from anybody about the gstreamer webcam support? By the way, this code is one of the sources that doesn't respect basic liquidsoap conventions. Concerning features I'm still a bit concerned about two points. (1) The clock API: Should clock() take a list of arguments, should it return unit? Is buffer() natural? (2) Several operators have a very general type, which can be a problem for two reasons: users could think their script deals with video but this is not forced by the type; there might also be operators that can't really process as many types of streams as they claim. We can leave most of that for later, especially if we declare that video is experimental and backward compatibility won't be preserved there. But some points could easily be enhanced: output.sdl only takes video (requires explicit dropping) and output.ao allows anything with at least one audio channel; this could be more uniform. Cheers, -- David ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d _______________________________________________ Savonet-devl mailing list Savonet-devl@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/savonet-devl
