Re: New API in 2.0.x ???

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

> On Wed, 16 Oct 2002, Owen Taylor wrote:
> 
> > > > 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....
> 
> with 2.0.6 you can create one custom fundamental type if you
> do the shifting, with 2.0.7 you'll have to not shift. so there
> is an API change.

But if it is an API change, it is an _incompatible_ API change,
so would require setting BINARY_AGE to 0. Which isn't an option.
So, I think we have to consider it a bug fix; in which case
we don't need to reset the interface age.

I decided to back out the interface age reset basically because
on some old crappy platforms, an interface age reset will cause
the solib major version to change. (SunOS, BSD up to a year or
two ago.)

Other than that, it just doesn't matter much. Solibs minor versions
are basically used for nothing on any platform.
 
> > > (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
> 
> neither is 32bit, which is why i was fixing the code.
> not having v_int64 would mean that 64bit scanning works
> on 64bit systems only, which is almost just as bad.
> ideally, v_int should have been changed to guint64 before
> 2.0 and the parsing code be fixed. now we didn't do that (and
> can't until 3.0), so i picked the next best solution which
> is giving people v_int64 and fixing the parsing code. i don't
> see a point in introducing an arbitrary limitation to 32bit
> scanning until 2.2 for 32bit platforms.

Well, any time you fix a bug that doesn't involve header
file additions you have to figure out if it was a bug fix or a
PAI addiiton.

(adding a button to an hbox crashes GTK+? Maybe the GTK+
API just doesn't allow buttons in hboxes.)

It is a bit of a judgement call.

In this case - from the header files and docs you would assume that
you would be able to scan the full length of an unsigned
long. Therefore, the s/strtol/strtoul/ change was a bug fix.

On the other hand, if there are changes to the header files,
then you can be pretty darn sure that it was an API addition.

In this case, the gint64 stuff wasn't in the 2.0.6 header
files. Adding it to the 2.0.7 header files would have been
an obvious API addition.
 
> > > (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.
> 
> well, i did 3 API related changes, and you don't even give those
> "one or two necessary additions". out of three items, you're
> trying to argue one not to be an API change, another to be not
> strictly necessary (sure, if 2.0.7 is meant to reproduce
> scanning bugs from 2.0.6), and the third to be an unnecessary
> feature (perhaps rightly so, but what's the point?).
> 
> however i won't fight endlessly over these issues, my time is just
> to precious to be wasted with pointless debates over why perfectly
> reasonable interfaces should _not_ be added to a library that
> facilitates binary and interface age versioning.
 
The point of having a consistent policy is to avoid debates ... to be 
able to say "OK, new API, goes in 2.2" and not have to think
about it further.

Regards,
                                        Owen