[Xcb] about api changes

[Barton C Massey]

A branch is a good idea as well, but we definitely need an
active discussion of what should be in it.

	Bart

In message <Pine.LNX.4.64.0706061848540.31850 at grozny.maths.univ-evry.fr> you wrote:
> 
> 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)
> _______________________________________________
> Xcb mailing list
> Xcb at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xcb