mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-11-29 21:21:12 +00:00
80 lines
2.8 KiB
Text
80 lines
2.8 KiB
Text
|
|
||
|
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
|