Re: New API in 2.0.x ???

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

> On Sun, 13 Oct 2002, Owen Taylor wrote:
> 
> > 
> > Sat Oct 12 21:30:41 2002  Tim Janik  <timj gtk org>
> > 
> > 	* configure.in (GLIB_VERSION): up version number to 2.0.7, binary 7,
> > 	interface 0.
> > 
> > 	* glib/gstrfuncs.c (g_ascii_strtod): fix comment.
> > 	(g_ascii_strtoull): new function, acting like strtoull(3) in the C
> > 	locale.
> > 
> > 	* glib/gscanner.[hc]: fix 32bit issues with integer parsing and
> > 	support storing 64bit values in GTokenValue by
> > 	using g_ascii_strtoull().
> > 
> > I don't understand why these change (except for the 32bit issue) went
> > into the glib-2-0 branch. They add new API, so they should be
> > in HEAD only.
> 
> strictly speaking, we got three API changes in stable CVS.
> 1) g_type_fundamental_next() returns shifted fundamental IDs now
> 2) GScanner gained v_int64 and store_int64 fields
> 3) the addition of g_ascii_strtoull()
> 
> (1) is required to get custom fundamental types back to work.

Things were just broken here, so I don't think it was really 
an API change... what you got before was type ID's that were
neither shifted or not shifted but somewhere in-between....

> (2) is required to get 64bit scanning working beyond
>     sizeof(long)==sizeof(gint64) type systems

64bit scanning is not a feature of GLib-2.0.0. It shouldn't be
added in 2.0.x

> (3) is not a necessary addition
> 
> with (1) and (2) already causing an interface age drop to 0, i didn't
> see much point in leaving (3) as a 2.2 addition.

My concern isn't the interface age drop to 0, though I don't see it 
as necessary for (1).

It's that we are adding unececessary new API to 2.0.x. Even if there
are one or two necessary additions, it shouldn't mean that it is open
season for adding other additions.

Regards,
                                        Owen