Re: [gtkmm] Questions and information

[Chris Vine <chris cvine freeserve co uk>]

On Tuesday 24 June 2003 8:04 am, Murray Cumming Comneon com wrote:
> > From: Chris Vine [mailto:chris cvine freeserve co uk]
> > I think gtkmm should keep step with the Gtk+/gnome policy on
> > API breakage (ie,
> > none in version 2.*).
>
> It would be nice, but it's not the top priority. Maybe you would be more
> comfortable if gtkmm 2.0 had been called gtkmm 5.6. It's just a number. You
> are also ignoring the fact that gtkmm 2.4 will have almost no significant
> API breakage. I think it's ABI breakage that you are talking about.

No.  I am talking about API breakage.  To people who maintain distributions, 
(and for users on Unix-like systems, which almost all come with compilers) 
ABI breakage is not such an issue.

[snip]

> 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,

(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 
(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).

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, or of how software development 
takes place in real life.  It is also not the view taken by the Gtk+ and 
gnome developers, and I think your approach is unnecessarily holding back 
gtkmm.

> 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.  Their other 
option is to stick with out of date versions (which is what Suse have done).  
Taking the Redhat example, which version are you suggesting that they should 
ship?  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.)

Chris