Forum .LRN Q&A: Re: Install Documentation and Recomendations for dotLRN 1.0

Collapse
Posted by Jeff Davis on
I am planning to maintain 4.6 on an ongoing basis (rolling bugfixes back from the head and incorporating new modules). To that end, I am hoping that to cut a minor version every 4-6 weeks. I run my personal site as a checkout of the 4.6 branch as well which is nice although I think for a real production site that's not a possibility since you almost certainly need your own CVS repository for managing the release process.

One thing that is not going to go into 4.6 is the i18n work (and it will not be in dotlrn 1.0 either). I know Lars has been talking about timeline for a 4.7/1.1 release that would have the full i18n work in but I am mostly concerned with getting a clean 4.6/1.0 install working for now. I would think that for Heidelberg's test server you would have to be on HEAD for both openacs and dotlrn since you definitely want to be testing with the i18n code.

We want 1.0 out as soon as possible to increase adoption of dotLRN in general. The earlier we have a clean 1.0 the sooner everyone can start to focus on 1.1 (with the i18n work and improvements).  We also need a defined upgrade path. Seeing that the upgrade path for OpenACS (4.6 -> 4.7) is defined and dotLRN is just a bunch of OpenACS packages it seems logical that 4.6/1.0 -> 4.7/1.1 is the defined path.

We will obviously be running/testing/pushing 1.1 in Heidelberg. The server I am talking about here is more of a "get to know" dotLRN server for early adopters and local demos. We are tending towards 4.6/1.0 for this to help push 1.0 out the door and keep errors to a minimum for our early users (first impressions are important).

So the answer to my question is probably:

Use cvs based on the 4.6 branch if we want to start using dotLRN 1.0 now (updating it using cvs as needed). This way we will eventually have a local "clean 4.6/1.0 tarball" equivalent as general 1.0 testing and release progresses. I just hope that the update process using cvs (4.6 branch) isn't a bugger.

First impressions are vital. We missed out on a major opportunity when we were showing people latest code from cvs head - too much broke and the impression was created that dotLRN is unreliable, flaky software. We are recovering slowly from this after help from the team at Sloan. People here are willing to be told this is what we can do today and this is what we expect to do tomorrow (that's already better than you can get from Blackboard). But the bit you offer today *must* be rock solid.

Failing to give due weight to this would restrict distribution to enthusiasts and dotLRN will not reach the mainstream.

Blackboard has had 2 minor glitches in 15 months of running here. This is the sort of reliability you will need.

John,

come help dotLRN reach the stability you seek by joining in the dotLRN 1.0 testing efforts. Subscribe to the dotLRN testing forum (https://openacs.org/forums/forum-view?forum_id=66604) to stay informed. Or contact me directly if you have resources to offer like servers or man power.

We could use your help.

/Bart