[Building Sakai] K1 - uitils rationalization?

[David Horwitz]

Hi Chuck

I'm certainly not suggesting that we remove methods from the API, I'm
merely suggesting we mark them as deprecated in the case outlined. The
motivation is to reduce the code that the kernel team has to manage to
what is important to Sakai. I agree we need to make things easier for
contrib developers I suggest we do this by not changing the API's and
steering them to standard java libraries rather the sui generis  Sakai
methods. As I noted in the thread earlier I believe where there is a
good reason for having our own method this should be clearly noted in
the Javadoc too ("unlike commons-foo this method...."). I see this as a
case for minimal effort (reviewing the content of utils, adding
@deprecated and some explanatory doc) we can get increasing benefit
during the life of the 2.x

Regards

David

csev wrote:
> 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
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>