Here are some suggestions on how we can plan the releases for .LRN and a short term path for next releases.
Those are my 2 cents, please give us feedback so we all can create a road-map for the next 6 months or so...
1. The release cycles should be not that long (something already mentioned / planned by others)
2. Aim for 3 months medium-major releases cycles (i.e. official support for tools like evaluation, lors, assessment, wimpy-point, etc.; this is a change like 2.1 to 2.2)
3. Minor releases in between more often, mainly bug-fixing, small features (those are 2.1.1, 2.1.2, etc.; around a month release)
While this model is simple, is as well flexible, since we are a cooperative community, we can help each other and be sure that .LRN releases meets institutions needs.
Now the suggested plan for .LRN in the short term is:
.LRN 2.1.0rc1: First half of november 04
* needs some successful upgrades (at GT we'll at least 3 successful upgrades, plus Sloan will have its own) + plus few bug-fixes
.LRN 2.1.1: beginning of january 05
* Inclusion of TCL CR API for oacs-5-1
* Bug-tracker support for installation errors (e)
* New template for .LRN (from Sloan)
* Notifications on GC, blogger & news (e)
* release of oacs 5.1.3
.LRN 2.1.2: begining of february 05
* UI improvements (e)
* Official Manuals included (e)
* Official Jabber support? (e)
* IMS Enterprise support (changes on acs-authentication) (e)
* release of oacs 5.1.4
* probably other minor releases depending on needs
.LRN 2.2.0: april 05 (this might become 3.0.0)
* Don's new portal system included (this will make our lives easier for include stuff into the portal system), and I hope we can start testing on this year
* Registration system additions (in combination with assessment) (hd)
* incoming email processing (e) (from ctk-musea)
* release of oacs 5.2.0 (which includes many oacs core changes)
.LRN 2.2.1: may 05
* official support of lors, evaluation & assessment (e)
* probably we have more stuff to put inside, but I want to keep the plan for a six month, simple and based on the priorities that we have seen from several users.
All of them will include bug-fixing. (e)
While the dates are no rigid, for adopters (actual / future ones) its important to have a clear road to show and somewhat accurate dates...
Those (e) means who's gonna take care of it:
(e) = some e-lane partner
(hd) = Heidelberg
Anyone else willing to take something or include another thing, please tell us here, then we can even release stuff before than planned.
We want with these avoid forks from the institutions, which is always tempting specially because the slow bug-fixing / release process that sometimes happen. Maybe AndrewG can bring back to the source the Viena guys :)
.LRN Releases - Philosophy (http://openacs.org/forums/message-view?message_id=198537)
.LRN release process and roadmap (http://openacs.org/forums/message-view?message_id=176321)