[gtkmm] gtkmm and gnomemm release schedules

gtkmm development is now in-sync with GTK+ development, and we recently
froze libgnomeuimm. So from now on, I plan for gtkmm and gnomemm to follow
the GNOME release schedules. For instance, this is the GNOME 2.6 schedule:
There will be another one like it for 2.7/2.8, and so on, every 6 months.

This means, for instance:

- gtkmm 2.4.0 will be released 2 to 4 weeks after GTK+ 2.4.0.
- libgnomeuimm 2.6.0 will be released 2 to 4 weeks after GNOME 2.6.0. See
- If we have not wrapped everything before the freeze, it's OK, because it's
only 6 months until the next freeze. We can add API every 6 months. BUT we
can't _change_ API, so we do need to be careful. However, see [1]a.

The key to this schedule is that it's time-based. The schedule doesn't slip
- features are punted to the next release schedule instead:

[1] With these caveats:

a) We might break API/ABI a few more times than GTK+/GNOME, because C++ is
inherently more difficult to keep API stable, and because it doesn't hurt
anyone now that the world has woken up to parallel-installation:

b) We might not wrap 100% of GNOME. For instance, we did not want to wait
until libbonobouimm was finished before freezing libgnomeuimm. We will
freeze what is reasonably mature. If a module is completely new and unusable
then we will not freeze it.

C) We might not have any changes between gnomemm versions. For instance,
GNOME libraries sometimes make no API additions between major GNOME
versions, so there is sometimes nothing extra for us to do. We will probably
re-release tarballs with new version numbers, to keep us looking in-sync
with GNOME version numbers.
   Of course, it is a bit silly to use gtkmm/gnomemm version numbers to show
what version of GTK+/GNOME we wrap, instead of just showing the
gtkmm/gnomemm version, so this can get awkward. We must be careful.

Murray Cumming
murrayc usa net

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]