Forum .LRN Q&A: Re: What is required for the next .LRN release?

I think we should take small steps but many. "no new release" is not an option. "bugfix release" is the way to go, so your "Hack bug tracker" idea is definetly great as it will reveal what has to be fixed by dotLRN. Considering application packages as true OpenACS packages not much is left for dotLRN except the dotlrn package itself and lors & Co and maybe ims-ent. In future maybe imsld.

We should really have the same what OpenACS has: a core. The dotLRN core should have no serious bugs.

All other application packages are integrated in dotLRN using dotlrn-* and the *-portlet packages. They are not too difficult to maintain since the first is almost the same in all packages and the second contains almost nothing except for the portlets.

So what it's really about are the application packages integrated in dotLRN. Here I would suggest the same policy as OpenACS does. They are not part of the core. There is only one difference: dotLRN is a product, so we need to guarantee a standard. Maybe we should certify that in correspondance to a maturity level a packages reaches. Below that level we don't recommend installation or upgrade and leave it to the decision of the administrator.

Regarding your third option I don't think that is is the job of the dotLRN consortium to take care of maturity levels. Even the installers are primarily the job of the community as are language support, xhtml compliance and themes. These goals depend more on the application developers or are part of the community process. Of course they are important for dotLRN but we cannot want what is not there. There really should be a separation of concerns or money. The first means dotLRN has to wait until the code is available the latter dotLRN has to raise money to make the code available.

Since there is also a commitment from dotLRN consortium or dotLRN institutions we should accept what is offered. From what I know there is some theme work going on in the community and also some have committed themselfs for the installers. If these effort bear fruits let's release them if they don't then don't. All we need is someone who set out deadlines for these activities and do some coordination.

I think we really should focus on dotLRN core bugs and work on the upgrade from OACS 5.1 to 5.2. Let those developing important packages like forums, faq, news, bulk-mail, assessment, evaluation, file-storage take care of maturity levels. This is a never ending process anyway. I have posted some thought on the maturity level here [1].

So here is my suggestion:

1. Release 2.1.2 with oacs-5-1 (bugfix release)
2. Release 2.2 with OpenACS 5.2 once 5.2.x is released (5.2 upgrade release) The ".x" is just an attempt to reduce the risk of broken important packages. Which the community has to take care of anyway.

- Since *-portlet and dotlrn-* packages don't really change new versions of the corresponding application packages will be available via the online upgrade anyway. So all we need to do here is to increase the version numbers so that they reflect a new version of the application once that exists.

- Work on a stable Lors & Co. release with an upgrade to lors central. This application is essential for any learning management system.

[1] https://openacs.org/forums/message-view?message_id=301726