RE: [gtkmm] Questions and information

[Murray Cumming Comneon com]

> From: Chris Vine [mailto:chris cvine freeserve co uk] 
> On Wednesday 18 June 2003 12:53 pm, Murray Cumming wrote:
> > On Wed, 2003-06-18 at 12:16, Dean Kutryk wrote:
> > > So what I'm wondering about is the future of Gtkmm.
> >
> > 1. GTK+ and GNOME will clearly be very successful and 
> widespread in the
> > future. Many companies need them. They have a bright future.
> > 2. gtkmm has matured and demonstrated more understanding of API
> > stability than most proprietary toolkits. Over the past few years we
> > have had the following stable gtkmm releases: gtkmm 1.2, 
> 2.0, 2.2. gtkmm
> > 2.4 has already been started. We are state-of-the-art. 
> Nobody else is
> > even up-to-date with modern C++
> 
> The present (or, at least, recent) approach to API stability 
> in gtkmm is not 
> to break API (and indeed ABI) between extra-version numbers, 

It's not clear what you mean by "extra-version numbers". I think you mean
the x in 1.2.x.

> but it does 
> permit API breakage between minor as well as major number 
> versions.  At any 
> rate, your initial posting announcing gtkmm-2.3 indicated API 
> breakage would 
> be acceptable with respect to gtkmm-2.2.

The sensible API stability policy is there. It's just a question of version
numbering that you don't seem to like. Sure, we'd like gtkmm 2.4 to be
called gtkmm 3.0 instead to make it absolutely clear that there is API/ABI
breakage, but it's also important to show that it is a wrapper of GTK+ 2.4.
I don't think the version number will shock people too much.

> This may have changed, but if not I doubt it shows "more 
> understanding of API 
> stability than most proprietary toolkits", in the sense in 
> which those who 
> write proprietary code which use them are likely to understand the 
> expression.  gtkmm's policy no ABI breakage between extra 
> version numbers has 
> however seemed to me to be exemplary, and perhaps that is 
> what you meant?
> 
> gtkmm is certainly state-of-the-art, which unfortunately 
> tends to pull in the 
> opposite direction from API stability.

No, stable API branches are not affected by unstable branches. Unstable
branches stabilise when ready. You would be best to discuss practical
problems with this policy if you think any exist. 

Murray Cumming
murrayc usa net
www.murrayc.com