breaking libsoup API - a technical question and a policy question

[Dan Winship <danw gnome org>]

Hey. So I've been hacking on the libsoup-2.4 branch of libsoup for most
of the GNOME 2.22 release cycle, breaking API to fix various problems
(ugly/confusing API, insufficiently-glib-like API,
non-language-bindable-API, API that needs to be changed to fix HTTP
bugs, API that needs to be changed to add hooks for new features [eg
http://live.gnome.org/LibSoup/DesktopWideHttp], etc).

It is now pretty much ready to merge to head (including a
porting-from-2.2 guide in docs/reference, and I have patches for all of
the other apps in jhbuild that depend on libsoup [bug-buddy, evolution,
evolution-data-server, evolution-exchange, evolution-webcal, libepc,
rhythmbox, seahorse, swfdec]), however, I am somewhat dubious about
actually merging it at this point...

As I understand the release rules, nothing actually stops me from
breaking libsoup's API up until hard code freeze, because it's in the
Desktop, not the Platform. But at some point it pretty clearly starts to
violate the *spirit* of the release rules though...

The real issue at this point is, there's been a fair amount of
underlying code churn in libsoup, and I figure there's got to be at
least one or two new bugs as a result. But since libsoup 2.3.0 doesn't
contain any major new features or bugfixes relative to the last 2.2.x
release (it's mostly just API improvements, with a handful of minor
bugfixes and features added), and we're now on the eve of feature
freeze, the net effect of releasing libsoup 2.4 from the perspective of
the modules already using libsoup would be "replace known good code with
possibly buggy code".

The people who *would* benefit from putting libsoup 2.4 into GNOME 2.22
are they people who *aren't* already using libsoup. Libsoup 2.4 is
essentially the "I'm not at all embarrassed to recommend it any more"
release :-). Plus, 2.4 will hopefully also ship with python and C#
bindings, putting even more people on the path to GNOME-integrated HTTP
goodness (albeit in a future release, since the release with GNOME 2.22
won't have automatic-proxies-from-GConf and automatic-passwords-from-
gnome-keyring support yet).

OTOH, if I don't put libsoup 2.4 out before GNOME 2.22, I'd probably put
out 2.3.0 the day after 2.22, meaning any work targetted for GNOME 2.24
would still be able to use it anyway. It's only stuff independent of our
release cycle that would suffer.

So anyway:

  Pros of putting libsoup 2.4 in GNOME 2.22:
    - Language bindings available for people to use sooner
    - Nicer C API available for people to use sooner

  Cons of putting libsoup 2.4 in GNOME 2.22:
    - Inconvenience to other module maintainers
    - Standard risks involved in changing lots of code at this point in
      the release cycle

So what do you think? And if I'm going to do it, when? At this point,
I'm thinking next Tuesday (ie, after the 2.21.5 tarball deadline, but
still two weeks away from the beta1 deadline) makes the most sense.

Oh, that was the policy question. The technical question is, if we
decide to not put libsoup 2.4 into GNOME 2.22, can I still put a 2.3.0
tarball on ftp.gnome.org (for people to test out and give feedback on),
or will that cause it to automatically get sucked into GNOME 2.22?

-- Dan