Hey,
Branches exist for that. I think that a 1.1 branch can be created, which
is the development branch of the next release (1.2), or something like
that. That branch can then contain the python parser, with api break.
gstreamer manage releases like that.
what do you think ?
Vincent
On Wed, 6 Jun 2007, Christoph Pfister wrote:
> Hi,
>
> There were some suggestions for api-incompatilbe improvements recently
> especially with regards to the new python generator. I'd suggest that
> you put them on a wiki page / create an experimental tree showing
> stuff / etc as it seems more and more likely that such an api breakage
> will happen at some point in future.
>
> Therefore I think it would be a good idea to have a process for that
> stabilization consisting of stuff like a) keep track of proposals (as
> you don't want to break the api again & again it's crucial if you
> forget certain points), b) review / discussion / show it concretly
> somewhere, c) freeze for a certain time and d) change it in one go and
> be happy :-)
>
> Christoph
>
>
> PS: some items I remember off the cuff:
>
> - iterator "mess" (e.g. quite some duplication of code for those
> iterators which just point to an entry in an array; maybe only having
> iterator_t *xcb_...s() and int xcb_..._length() for that type of
> iterator), ".rem" is named +/- well
> - some points about naming normalization
> - should the _request stuff be part of the public api? (e.g. compile
> time speedup if the headers are smaller)
|
