| After some discussion on IRC, I think it's time to propose a | |
| formal plan for the next 6 months or so to the list. | |
| I think most people are in agreement that we need a period of time | |
| in which we can focus on improving non-core bits (like elements, | |
| schedulers, autopluggers, applications, etc.) In the last cycle, | |
| there was a lot of time spent with a significant number of plugins | |
| broken, and it's realistic to assume that this could happen again | |
| in a 0.9 unstable series. | |
| What I propose is: | |
| - We continue to develop the 0.8.x series as HEAD, with the obvious | |
| requirement that all changes be ABI/API compatible. | |
| - API additions are encouraged, as long as they are well-thought-out. | |
| - Significant API additions should be developed on a separate branch | |
| (not HEAD) to test out any bugs. | |
| In mid-August (or so, in order to coordinate with GNOME-2.8), we have | |
| two options: | |
| - Continue with 0.8.x releases, obviously ABI compatible with 0.8.0. | |
| - or, remove deprecated functions, readjust the padding on structures, | |
| perhaps make a few additional ABI changes [1], and quickly go to | |
| 0.10.0. | |
| I prefer the latter, although we don't have to decide that until | |
| later. In either case, there should be no API changes that affect | |
| more than a bare minimum of elements or applications. | |
| A few things that we won't be able to do without a true unstable | |
| branch are: | |
| - using GstStructure for all GstEvents. | |
| - significant clock changes | |
| - significant scheduling changes | |
| - separation of headers into application and plugin headers | |
| - anything that requires modification of every plugin | |
| There are perils with having HEAD being the stable branch, | |
| specifically that bugs can creep in and accidentally cause regressions | |
| in releases. I'm hoping that the introduction of media regression | |
| testing and also the development of new testsuites will keep this | |
| to a minimum. Don't forget that accidental bugs that get into | |
| releases typically cause rude IRC conversations, which we really | |
| don't need. Please keep the bugs (and the rudeness) to a minimum. | |
| Also, keep in mind that we will have to live with 0.8's unfixable | |
| bugs for an entire year.[2] | |
| dave... | |
| -- | |
| [1] I'm thinking about making GstData a subclass of GTypeInstance or | |
| GObject. | |
| [2] But then, 0.6 was 1 year ago, and felt a lot more buggy when it | |
| was released. | |
| ------------------------------------------------------- | |
| This SF.Net email is sponsored by: IBM Linux Tutorials | |
| Free Linux tutorial presented by Daniel Robbins, President and CEO of | |
| GenToo technologies. Learn everything from fundamentals to system | |
| administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click | |
| _______________________________________________ | |
| gstreamer-devel mailing list | |
| gstreamer-devel@lists.sourceforge.net | |
| https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |