blob: 4a54bb808444483bfdf850a3682e8f44f3cfba16 [file] [log] [blame]
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
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]
[1] I'm thinking about making GstData a subclass of GTypeInstance or
[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
gstreamer-devel mailing list