Forum OpenACS Q&A: Feature creep, stable releases and 3.2.5 vs. 4.x
(First, I would like to thank everybody who answered to my dotLRN forum question).
I think my concerns regarding stable release will be relevant to those planning to make investment into OACS based site. I want to build my small consultancy site which I hope to turn into a community. I've been following ACS since 2000 and would love to use the platform. I am not a programmer. I know some Linux administration and HTML design as a hobby, but all I really need is to fill the site with content and business logic.
I have a problem deciding which OpenACS version to use. Version 4.5 is powerful, and exists for 1 year as beta. I am really exciting aobut all the complex business processes I can implement there, and would like to start building on top of it (and learning by doing). But then I have this feeling that maybe it's a "transition" copy which will be poorly supported later. Threads speak today about changing data structures, depreciating modules; versions 4.6 and 4.7 are mentioned. I know that there will be upgrade scripts, but I don't like the idea of investing time again to re-install and re-tweak the system.
Since I'm a user, not a developer it seems I should stick to 3.2.5, however strange it may seem. Yes, it is obsolete in some ways and less efficient, but I may be sure that it is very well-known and I will have to move my data only after 1-2 years and possibly later. I am speaking not about run-time stability, but about protection from feature creep and design changes.
I think OpenACS community will demonstrate maturity by introducing "better less but better" principle as to new releases and being really perfectionist about polishing existing ones. Who would invest in poorly supported bloatware?(Not that I consider OpenACS a poorly supported bloatware... ;) )
So, would you advice me sticking to 3.2.5 or is 4.5 stable enough to use as a foundation? On my side, I intend to document my learning process and contribute to prospective user manual.
What you are describing is the normal evolution of *any* software product. The difference is that because its an 'open' product you have transparency during development. Just because you can't normally see the process, doesn't mean its not going on in any other product.
Therefore I think your comments are somewhat unfair.
Version 4.5 has not been in beta for a year, its been a stable release.
4.6 is due for full release in the coming weeks (rather than months).
Is 4.5 stable enough to build on.. Yes.
If you're strating a new development should you use 3.x.... No.
If your delivery isn;t going to be finished in the next couple of weeks (which I guess is the case) then I'd base it onthe current 4.6 pre-beta. It shouldn't be too difficult to work in bug fixes etc once the full release is out...
I'd also like to take issue with 'I think OpenACS community will demonstrate maturity by introducing "better less but better" principle'
Thas exactly what is happening. 4.6 is not a major functional overhaul, its very much a consolidation release based on things found in 4.5...
OpenACS 4 in general has a *much* better foundation/design underpinning that 3 (whihc frankly looks dated these days) and has maintained a reasonably stable data model core throughout its development.
So, hope that advice helps, and hope thats set OpenACS 4 in its proper context.
and all the effort towards perfection and polish are taking place
in the 4.x version. It is not a "transition copy" since there are
no plans to do anything other than make further evolutionary
changes to the code base (all of which should be upgradable). Furthermore, 4.x has very significant advantages
over the 3.x version in terms of design, modularity, upgradability, and
functionality. So, while you can build a site (and a business maybe)
on 3.x, 4.x is almost certainly the prefered choice.
Also, in the next
month or so 4.6 should be released and I think you will find that
quite a few of the 4.5 bugs have finally been ironed out.
We have used 3.x, 4.5 pre alpha, 4.5 alpha, 4.5 beta and 4.5 stable on our production sites. A good number of them are in 4.5 beta. I think 4.5 has proven itself to be a production ready code. Also using 3.x and going to 4.x you will have to unlearn some stuff. I think its best for you start in 4.x since you have the benefit of having a fresh perspective.
This is still in the 4.5 tarball.
It took nine months to make producton-quality release (4.5), and now instead of getting maintanance releases (4.5.1 etc.) there is 4.6. Again in beta. By contrast, 3.2.x has been a production release since May 2000 and receives only maintainance releases since then. Which one looks more stable to you?
What you're arguing about is a marketing issue, not a technical one. aD released a buggy, bloated system and called it production ready. The community has been cleaning it up, albeit for a long time, and has waited until it was in proper shape before releasing it.
There's really no reason to worry this much.
4.6 _is_ the maintenance release for 4.5. There's no rule saying that we must release maintenance releases as another dot.
4.7 will be the release which will have more significant modifications to the core.
It's true that 3.2 has had "production" status for longer than 4.x, but it still had some pretty horrible bugs that were uncovered and had to be fixed.
The degree of production-readiness varies a lot throughout several parts of 3.2. 4.5 however, is in much better shape, and 4.6 much more so. You have to realize that the release standards that OpenACS goes through are in average much higher than those that ArsDigita used, judging by some of the code that was released.
4.x simply offers so much more in terms of ease and consistency of development, with so much more real-production-ready code that it's hard for me to find time to even go back to 3.2 series to work on its maintenance. Much less want to develop a new site with it.
Regarding the standards used at openacs and arsdigita: I was referring exclusively to the 4.x release, which was released uncompleted due to the whole management break-down.
I never meant to bash or rant about ArsDigita or its developers. I think they did an outstanding job in many parts of the toolkit, and I am really thankful that they made it all available under the GPL (as is mentioned in our homepage and throughout our documentation).
I am also considering moving my old Apache/Perl home page to ACS. But I am not sure I would want to use 4.x for this.
My concerns, however, are of a slightly different nature. If one recalls, one of the arguments for AOLServer that Phil used to give was the fact that while you can build a database-backed website, you do not have to tie yourself to the database 100%.
If I am not greatly mistaken, the beauty of 3.2.5 is that even if Oracle/Postges are down you can still use static content of the site. Bboard/commetns will not be available, yet you plain .html page will be there.
It is not possible (or at least I don't know of a way) to do it in 4.x, as all the URLs in address bar are not 'real'. If a database ever fell over, anybody hitting a page on a site will get something like 'Could not allocate a database pool, yada-yada-yada'.
I notice an interesting rise in the number of new people registering on openacs.org. Why not add a poll to the homepage, so we can find out what people are expecting to to find. It may also be interesting to know their role, (hacker, developper, marketing, management, end user). As a follow-up we could create user initiated whishlist, that may help to create a priority todo list for things most wanted by user of the toolkit. Just a thought
OK, here is my "pure marketing" suggestions. I suggest that a release policy document be published on the site. For example, major version means architecture change (3->4), minor branch means functionality addition/change (4.2->4.5), and further "dots" mean bug fixed (4.5.0 -> 4.5.1). Something along these lines maybe (p.3)? That would help. And many thanks to everybody for the advice. I understand 4.5 is production qualtiy release, 4.6 will be bug fixing release, and 4.7 will have large changes to the core.
You don't have to have the database to serve up static pages... AOlserver will still do that regardless.
AOLServer will, but not coupled with OACS 4.x. For example, /doc is not really a /doc under $serverroot (or %pageroot -- cannot remember config variable name right away), but rather is a part of acs-core-docs package. You cannot browse it unless OACS has started up AND URL-to-package-whatever-function returned the real URL path to /doc (which will be $serverroot/packages/acs-core-docs/www/). You cannot even get to $serverroot, in fact -- only to www under it.
Obviously, one can still create whatver directory under the www and put plain-old .html there and knowing full path still be able to access it.
that's as it should be. But, if with the DB down, you want the
OpenACS request processor to allowing global permissions to certain
directories, then that's just a SMOP - a Simple Matter of Programming.
It could be done, it's probably not too hard either. Configuring
things so that an on/off switch in the AOLserver config file would
allow, say, access to documentation for all packages under the /doc/
URL is feasible, it just might need some thought to design a nice
solution rather than a quick hack. That sort of thing might be a nice
feature for times when, say, your database is down and you want to
read your online docs on how to fix your database...
But really, none of that solves any truly pressing problem. E.g., you
still have to be prepared to fix things when BOTH your database and
web server are down. And most of the more powerful and interesting
functionality needs the DB. So that's probably why you haven't seen
anybody else put in the time to make that happen.