[Building Sakai] KNL-205 binary incompatibility

[Stephen Marquard]

I dug out the off-list mail thread, and it was basically the same ground covered here, viz. "why not deprecate the methods rather than change them, and if they're incompatible it requires a major version number change" and the same response. I've added a fuller comment to the JIRA - http://jira.sakaiproject.org/browse/KNL-205 - outlining the options and tradeoffs, and a link to the original sakai-dev post.

I hope that sets out the full case for this, though you may not agree with the current result.

FWIW I'm agnostic on the version numbering issue and whether this should have required a K1 jump from 1.0 to 1.1 or 2.0 or whatever. I just did the code changes to enable 2G+ file sizes in CHS, and co-ordinated significant related changes to eliminate all the related use of byte arrays for handling content bodies across a number of services and tools, which is good for everyone because of JVM memory issues (even for cases < 2G).  A number of these fixes (i.e. use streams rather than byte arrays) have been merged back to 1.0.x though not the API changes or 2G+ support.

Regards
Stephen 
 
>>> Ian Boston <ian at caret.cam.ac.uk> 2/3/2010 6:14 PM >>> 

On 3 Feb 2010, at 14:32, Stephen Marquard wrote:

> The alternate position that has been argued (some commentary may be in the JIRAs, others off-list) are that we should do (2) by introducing a new method getLongContentLength() and leaving the int method in place. 


I know this is long gone, if I had been paying attention I would have said

+1 (non binding), but modify the impl of getContentLength() to warn in some way if > 2G. (log message, runtime exception) From the patches on KNL-205 it looks like if anyone tries a large file the are still in danger of crashing a JVM.  (On the basis one of them is in wiki, I am probably guilty there)

BTW, the Jira only contains your comments.

Sorry to have opened a can of worms I just wanted to understand why there were binary incompatibilities between kernel API's without deprecation.

Looks like you have a strong case for as many version numbers as you want. We will have to manage the pain in Kernel 2 (formally known as)

Ian