There probably is no real reason why it took so long to be released. Up until 0.7, xmonad was facing roughly a 1-2 month release cycle with alot of rapid and rabid development in between. The fundamental changes to xmonad 0.8 since 0.7 are minor, and fall chiefly in the refinement category. It seems that development to xmonad has become relatively stable. One of the reasons to push the release was that there was so little development on the core parts to begin with. So the decision was made, and the release went by really smoothly.
This does not mean that xmonad is starting to die out. There are two things that make xmonad radically different than many other window managers. First of all, xmonad is based on some fundamental mathematical principles and data structures common to the functional programming world. The original goal to produce a functional window manager (no pun intended, although feel free to interpret one in ;) ) has essentially taken a year to develop from start to finish. It also uses some highly testable development methods including unit tests exposed to QuickCheck, the haskell unit tester, that greatly increase stability. Stable, if slow, development of xmonad implies that after a year of public usage, all the boiler plate code around the window manager has been refined and tested by a large number of users into some elegant minimal code, and by minimal, i mean 1045 significant lines of code style minimal.
The second important component is the contrib library, which is really quite essential to development. It is another ~9000 SLOC with a number of components to make using xmonad far easier and more flexible. In the true functional style, they are just a bunch of user submitted functions that different users have found useful for others too. For example, it includes fancy advanced layouts, layout combinators, alternate syntaxes for window management and key commands, random tools for outputting important information to dzen, or other tools, and for interacting with other parts of the system. Not a single line of code is actually run unless the user uses it.
The config file itself is actually just a haskell program cleverly disguised as a config file. In this latest release, there is an add-on in contrib that will even convert other config file formats into a haskell file, compile it, and run it, all in the background. The only components that are included in the run time are the ones being used. Of course, as a user, you never need to work with compiling your own xmonad window manager; part of that 1000 lines of code is the boilerplate to automatically look for your ~/.xmonad/xmonad.hs, compile it, and load it up, without much trouble. You can even make changes, reload your WM, and that same boilerplate will just pass your session on to the newest version.
I've built some packages, which are available at my personal repo at:
If you are already using my packages and repo, you should automatically get updates through yum. These packages are currently for Fedora 9, i386 only, but if anyone submits some builds for other archs/platforms, i'll be glad to stick them in the repo.
On a side note, I'm having some trouble signing my packages. Anyone know how to make sure rpmsign is using the right gpg key to sign packages?