RE: [gtkmm] Questions and information

[Murray Cumming Comneon com]

> From: Chris Vine [mailto:chris cvine freeserve co uk] 
> > You have not addressed my point that a new API is not a 
> problem because it
> > has no effect on your use of the old API. You have not yet 
> mentioned any
> > practical problem.
> 
> The problems are I hope self-evident:
> 
> (i) People writing large projects do not want to re-write 
> them at unecessarily 
> frequent intervals in order to have them compile on a version 
> of the library 
> which is still actively supported, distributed and maintained,

But both stable and unstable branches are maintained. Distribution has
nothing to do with us.

> (ii) People writing large or small projects want their 
> project to compile on 
> as many distributions and releases as possible, and not to 
> break on each 
> occasion that a distribution moves to a more recent release 
> of the library 

There is no reason why a distribution can not ship all fairly-current
versions of an API. For instance, everyone ships GTK+ 1.2 and GTK+ 2.x. The
problem does not exist.

> (and where there are API breakages, they want to deal with it 
> by a few 
> #ifdefs which pick up version definitions obtained at the 
> configure stage in 
> order to keep a wide user target).

Yes, deprecation is kinder than breakage and we will do that where possible.
We might do it via #ifdefs or via an extra library.

> I know you think this is nonsense because a user or a system 
> distributor can 
> always stick to an old version of the library, but that does 
> not take account 
> of how systems are distributed in real life,

Do you have a real-life example? It's real life that we think we are dealing
with here.

> or of how 
> software development 
> takes place in real life.  It is also not the view taken by 
> the Gtk+ and 
> gnome developers,

The API stability policy of gtkmm is directly inspired by that of GTK+ and
GNOME. You are just arguing about when the API breaks should happen and what
version numbers we should use. You do realise that there is going to be an
API-breaking GTK+ 3 eventually, and an API-breaking set of GNOME 3
libraries.

> and I think your approach is unnecessarily 
> holding back 
> gtkmm.

I see no evidence of that. You seem to be suggesting that we should never
have done anything after gtkmm 1.2. If we had done that then we wouldn't
even be talking now.


> > As far as I know, the specifics of our API stabilities 
> plans have nothing
> > to do with distro's decision to ship gtkmm. Most distros 
> ship libraries if
> > they also plan to ship applications that use gtkmm. Of 
> course there are
> > other reasons to ship a library:
> > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=82473
> 
> I would be surprised if a distributor wanting to maintain the 
> reputation of 
> the distribution would want to ship a library which requires 
> those who use it 
> to rewrite their code at unnecessarily frequent intervals.  

I'll repeat myself one more time. We do not require people to rewrite their
code at unnecessarily frequent intervals. You rewrite it when you feel like
it.

Again, no distribution has ever told us that there is anything wrong with
our API policy. Distributions have to deal with countless flaky libraries
with almost no concept of API stability. They'd love it it everyone was as
disciplined as gtkmm.

> Their other 
> option is to stick with out of date versions (which is what 
> Suse have done).

Do you have the slightest evidence that ths is why SUSE is not shipping
gtkmm 2?

> Taking the Redhat example, which version are you suggesting 
> that they should 
> ship?

gtkmm 1.2 and gtkmm 2.2 ideally. And then gtkmm 2.4 when it is stable. Where
is the problem in that?

>  More generally, I do not agree that C++ libraries need 
> to break API 
> more frequently than C libraries.  (I agree that it is more 
> difficult to 
> maintain ABI compatibility with C++, but as I have mentioned 
> I do not think 
> that that is such an issue.)

Well then I don't know what you are complaining about. I have already said
that the API breakage will be very minor. But, though you don't believe it,
ABI breakage (or never having ABI breakage in an API version) is the major
concern here.

Remember, API stagnation is not an alternative. gtkmm 1.2 was not good
enough.

Murray Cumming
murrayc usa net
www.murrayc.com