[Building Sakai] K1 - uitils rationalization?

[csev]

Rationalization is a great idea and deprecating is OK - particularly  
if the messages are really clear and perhaps someone writes a document  
page about how *exactly* to switch to the new/right APIs.

I think that at some level we are getting *well * the point where non- 
upwards compatible API changes to the 2.x / K1 code base have a  
strongly negative cost benefit regardless of how "elegant" the changes  
are.

With the Sakai 2/Sakai 3 already splitting our energies and many  
schools assembling their production build from a combination of core  
and contrib and their own repos - we need to make the lives of contrib  
developers as comfortable as possible for the rest of the 2.x / K1.

We have seen the impact of the K1 refactor (something wonderfully  
elegant and something I strongly advocated for in 2007) and how long  
it has taken to release 2.6 - because the elegant changes were done  
and about the time there was no going back - the primary K1 resources  
all left onto other projects.

I think that it is time to accept the fact that the 2.x code base  
needs to take a VERY conservative approach to non-upwards compatible  
API changes.

At the same time, I think that Sakai 2.x has a long and happy life  
ahead of it - and needs investment and improvement - but we can work  
on things that make the software better/faster/more reliable/more  
usable *without* improving the elegance of the APIs.

So my opinion is that refactors of APIs are perhaps our *lowest*  
priority and perhaps the most harmful of all steps that we can take at  
this point in the code lifecycle.

If my vote mattered I would vote -1 even on deprecating.

Why bother?  What is*broken* that needs fixing?  How many  
conversations to explain the changes will have to happen about this  
from our far-flung developers and folks who want to pull bits and  
pieces from trunk for their production???

/Chuck