Dear Timothy,
Sorry for the delay in reply -- been very busy lately.
I think release scheduling is just a conundrum that no one has yet solved.
It is a true-ism in the industry that *all* software projects fall behind schedule.
You can make all the timelines you like, but...
Money isn't the issue either: look at Microsoft's Longhorn.
On the other hand, rigidly sticking to a schedule like IBM did with O/S 2 or the other example posted here means endless patches for bugs and a lack of features in the release.
A roadmap with an approximate timeline which is adjusted regularly is about the best one can hope for I think.
One thing that helps is a feature freeze and a goal for release date like the linux kernel and others do, but they STILL slip. Sometimes for months.
What is being done is optimal and encouraged generally: release early, release often. Let the dare-devils test as much as possible before declaring something stable, but the code is still available the entire time if someone *really-really* wants it for production use.
As for my own copy, it's a very, very changed version of a 1.4x cvs (around last June) -- I couldn't upgrade if I wanted to. I just had to bite the bullet early on and add fields, tables functions etc. No way around it for my needs.
Anything cool that I want I need to port to my own version. Trust me, I really tried very hard to avoid this eventuality during my design phase, but I just couldn't.
And I'd still make the same choice for Moodle today. It's just perfect for my needs. I think I only use around one quarter of its capabilities. Using Moodle saved me months and months of devel time and I'm very grateful for the efforts of Martin et alia.
Unfortunately, I'd also still have to choose to modify the heck out of it and face the same problems again
If I had to implement one myself, right this minute, I would choose the stable 1.4 and be able to convincingly promise additional cool stuff for September. I would not upgrade an existing production 1.4 to 1.5
I *would* patch the existing production 1.4 for any serious bug fixes from the 1.5 tree that effected me though. Just wouldn't add anything new and not well tested.
In point of fact, I usually wait a couple of months after a dot zero release of *anything* to upgrade: distro, kernel, program -- whatever.
But, like I said above, there is absolutely *nothing* stopping *anyone* from playing with the cvs version or even running it in a production situtation if they have an extreme aversion to sleep and calm nerves.
As far as I'm concerned, a dot zero release just means a certain (subjective) confidence level on the part of the release master for a certain cvs version. In reality, it means nothing concrete. Every project is always in some late stage of beta that is 'close enough'.
Say Timothy, how's your unix learning progressing? Did you decide for bsd or linux in the end? Whichever you chose, you are well on the road.
Cheers!