GNOME User FAQ
Found at: http://www.linux.org.uk/~telsa/GDP/gnome-faq/index.html
What follows is current as of 8-6-2004:
GNOME FAQ
| Date | Event | Rough version number |
|---|---|---|
| August 1997 | Miguel de Icaza posts the initial GNOME announcement | |
| December 1997 | The "GNOME tarball" | gnome-0.10 or so |
| January 1998 | gnome-0.12 | |
| September 1998 | The tarball splits and becomes more than one package. "Bouncing Bonobo" release. | gnome-core,libs,utilities,media 0.30 |
| December 1998 | Ramping up to initial release | gnome-core 0.99.1 |
| March 1999 | GNOME 1.0 released to the world at large. This shipped on several distributions. | gnome-core/libs 1.0.4 or so. |
| October 1999 | October GNOME released | gnome-core/libs 1.0.50 or so. |
| January 2000 | Start of test releases for next big upgrade | gnome-core-1.1.x and gnome-applets-1.1.x |
| May 2000 | GNOME 1.2 released. Also known as Bongo GNOME. | gnome-core-1.2.x, gnome-applets-1.2.x, gnome-libs-1.0.60 or so. |
GNOME uses a version number system that is very common on the net now: it's also used by the Linux kernel, the mutt mailer, and several other large applications. It's three numbers separated by dots, in an x.y.z format. Start with the first number. If it is 0, the app is probably still in development: it may be stable, but it may not have all the features planned yet. If it's 1 then look at the second number. Odd numbers mean it's unstable, at least nominally, or a development version. Even numbers (or zero) mean it's stable. So the gnome-core-1.1.z packages were unstable. When they became stable, they were released as gnome-core-1.2.0. The third number is simply a minor increment, denoting bug-fixes or small improvements. Note that it is not a decimal number. When you get to 1.1.9 in a package, the next number is quite likely to be 1.1.10.
Most GNOME packages seem to come out with memorable names: the October GNOME release, "Beantown" for gnome-core-1.1.1 and so on. The reason why so many releases of GNOME packages have inventive names may either be an attempt to make the packages more memorable, or they may be a reflection on the minds of the developers.
Second, although they look very similar on top, the way each works underneath is very different. You couldn't just take code from one project and plug it into the other. It's not that simple. You can run some KDE programs from within GNOME and vice versa, but making them work any more closely is hard.
Finally, it's worth pointing out that whilst the code in the two projects can't work together, this is not necessarily true of the developers. GNOME developers and KDE developers do actually talk to each other. It's even rumoured that some of them get on quite well.
| Next | ||
| GNOME platforms and support |