Forum OpenACS Development: Re: Clarification of Upgrade milestone criterion

Collapse
Posted by Joel Aufrecht on

I don't understand what "our criteria probably needs to expose the fact that we run into such problems." means. Could you explain more?

I propose that our upgrade criterion not distinguish between work/risk caused directly by our code and work/risk caused by underlying platform changes necessitated by our code. If I have an OpenACS 4.6.1 site which I want to upgrade, I have certain set of problems which I _must_ fix in order to upgrade, regardless of their origin.

In other words, if there is a code change in 5.0 that requires a platform upgrade, the work of the platform upgrade should be counted against meeting our upgrade criterion. This will have the effect, I hope, of encouraging more backwards platform compatibility, which is more work for OpenACS developers but a Good Thing for users. We should also continue to address the "more work" part by providing more resources for developers along the lines of the test servers. That way, new code can be tested against older platform combos without requiring developers to maintain a full suite of old software.