[openbeosstorage] Compatibility Policy
- From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Mon, 22 Apr 2002 19:05:09 +0200 (MET DST)
Hi,
I wonder, if there is a guideline, how to deal with R5 compatiblity
issues. I don't mean general binary compatibility, but kind of behavioral
compatibility, concerning e.g.:
* R5 bugs:
Shall R5 bugs be reproduced by OBOS? Some applications rely on bugs.
* R5 inconsistencies:
Shall inconsistencies of R5 be reproduced? I don't have the code at
hand, so I can't give an example, but I remember, that I had two
versions of a method, that returned different results for the same
input. Boolean methods, btw...
* error codes:
Could probably be subsumed under inconsistencies as well.
For instance the return value, when invoking a method on an
uninitialized object (a method that requires it to be initialized, of
course) varies from B_NO_INIT over B_FILE_ERROR, B_BAD_VALUE to crashs
(if we consider those return values ;-). Or passing a NULL value for a
required parameter might result in B_BAD_VALUE, B_BAD_ADDRESS,
B_NO_INIT or, again, a crash.
Personally I would like to have each of these items fixed (bugs might be
worth a second thought though).
Especially for the error codes I would like to have some standardization;
like what to return on what error and in which order to check for errors.
What do you think?
CU, Ingo
- Follow-Ups:
- [openbeosstorage] Re: Compatibility Policy
- From: Tyler Dauwalder
Other related posts:
- » [openbeosstorage] Compatibility Policy
- » [openbeosstorage] Re: Compatibility Policy
- » [openbeosstorage] Re: Compatibility Policy
- » [openbeosstorage] Re: Compatibility Policy
- » [openbeosstorage] Re: Compatibility Policy
- » [openbeosstorage] Re: Compatibility Policy
- [openbeosstorage] Re: Compatibility Policy
- From: Tyler Dauwalder