After this experience with working running an open source project like the .LRN core, I do have some thoughts about the most effiecient and succesful way to run it.
Basically, you get people that are activily using the latest release and you informally work together to make the software better and better. Each organization commits that in addition to fixing things on their own site, they also put their fixes into the core. Each organization commits to "be there" for the other ones if there is a crisis bug or project. When it makes sense for the code base, they tag everything up and release it for everyone else in the community.
That can be complimented by volunteers working on other projects, package contributions, etc.
In that sense, it is not like a product company where there "guarantee" certain things are going to be done, or that there is really a core development team or a structure like there is at a product company.
For .LRN, two 100% committed organizations right now to this model are Sloan and Galileo. I say this because I've been working closely with both and they have both upgraded (or are literally doing so) to the .LRN 2.1a so they are highly dependent on it. And they are also committed to staying close to the latest version and summitting their latest work to the active version.
There may be others interested in participating that way as well. A core team of about 5 schools or organizations would be ideal.
So, Malte, to answer your question, is the upgrade path "guaranteed". Here is what I can say:
a) Developers are supposed to commit upgrade scripts with their checkins
b) Yes, both Galileo and Sloan will be following the upgrade path so we are dependent on that
So there is a clear attempt being made.
But beyond that, nothing is "guaranteed". We won't be making efforts to test it in extra places and makes sure it works everywhere beyond Galileo and Sloan.
Bottom line, if you want to make something works for you
a) you test it
b) you are willing to put in some resources to help make it better
