Re: [Nautilus-list] GnomeVFS 1.0.2 Release

[Maciej Stachowiak <mjs noisehavoc org>]

On 19Sep2001 01:43AM (-0400), Havoc Pennington wrote:
> 
> There's room for common sense here. At one end of the spectrum, adding
> a five-line function like gnome_dialog_whateveritwas was something
> that led to people accidentally requiring new libs, and for some
> 5-line trivial function that could be cut-and-pasted, this was not
> worth it at all.

I agree that cases like that are lame. However, the additions here are
at the request of app developers (resolve_relative) or end-users (the
authentication stuff and the callback framework it uses). The first is
a relatively small but quite tricky piece of code, and the second
can't really be done properly outside of gnome-vfs.

> Another factor in the GTK additions was that they really weren't
> _useful_ except to theme engines anyhow, so there was a reasonable
> expectation that apps would not use them (and that prediction has been
> true so far).

I tend towards the opposite view - that additions are more acceptable
when they _are_ useful.

> On the whole my opinion is that changes like the gnome-vfs ones, if
> made regularly in all modules, are a big pain in the ass. I would
> agree that any single change is not a big pain in the ass, but
> everyone doing it once in a while means someone doing it all the
> frickin' time.

I would expect that these are the only API additions that will happen
between GNOME 1.4 and GNOME 1.4.1, and then probably none will be made
until GNOME 2.0.

> I think it's also nearly impossible to get decent testing on any
> noticeably complex API addition in stable, because you don't have any
> way to make beta releases. 

To some extent, I feel exactly the opposite way. There is no way to
get decent testing unless you actually use new APIs in an app and do
real end-to-end testing.

For this reason I feel much less confident about some of the API
additions in gnome-vfs HEAD than I do about these.

In fact, all of these new APIs were reviewed and refined, based in
part on the experience of using them in real code, after the first
cut.

One thing I do think could improve the situation though, is to require
new APIs to come with regression tests, especially ones that don't do
any I/O or user interaction and so there is no excuse not to write
test cases.

> And historically we've released several
> broken APIs (in both interface and implementation) for this reason. A
> way to solve this might be first releasing the API in a separate
> package and merging it when complete.

For resolve_relative this was in effect done (the code comes from
Nautilus) and for the callback stuff, it would have been impossible
since the new calls affect the way existing library mechanisms work.

> Anyhow, I do think we should have a policy here, I don't think it
> should be a boneheaded no-common-sense-allowed "if nm shows a new
> symbol you are evil" kind of policy, but also I would say 95% of the
> time adding API is wrong.

Why don't you write a policy up and propose it? While I am pretty
indifferent to forwards compatibility issues myself, I'm willing to
follow such a policy as long as:

* The time between releases when any kinds of compatible changes are
OK is not too long (GNOME 1.4 to GNOME 2.0 is definitely too long, 1.4
to 1.4.1 seems like a reasonable span.)

* The policy doesn't make it too hard for a somewhat literal-minded
person like me to make a judgement call (i.e. if the policy will help
prevent and resolve debate rather than spawn more). I do recognize
that you can't make it as unambiguous as the "100% backwards
compatibility within major platform versions" rule, but "just use
common sense" is definitely too vague.

Regards,

Maciej

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers