Regarding complaints about quality, I think there is greater understanding when version numbers more accurately reflect the ongoing evolution of OpenACS.
What is the difference between a minor release and a major release?
4.7d became 5.0 due to the number of significant changes to the core. See https://openacs.org/doc/openacs-5-0/release-notes.html
5.1 seemed to be a maturing of 5.0 with no new core features. See https://openacs.org/doc/openacs-5-1/release-notes.html
5.2 introduced callbacks and the kernel now requires acs-lang. AFAICT, these changes have resulted in significant coding change requirements to most all packages. Considering the time it has taken to get to release stage etc. why was this not changed to version 6.0? The release notes do not even mention callbacks: https://openacs.org/doc/openacs-5-2/release-notes.html
5.3 is still CVS Head, right? This version requires tcllib, and introduces xotcl, and a portals method right? Aren't these features creating yet another paradigm shift in programming packages for OpenACS? Shouldn't this be versioned to 7.0.. or at least 6.0?
When I tell people 5.3 is really version 7, they understand why OpenACS (as code, website and community) is exhibiting some of the symptoms that they see.
---
Malte, I think you've stated pretty well how things work (or are supposed to). Yet I have a couple of questions.
Can't package maintainers review other package code, and the OpenACS community review code? I do where I can.
Doesn't requiring OCT members to review code create a new technical/skills requirement on the team role which has not been there?
