Yep API bugs, where functionality doesn't reflect intent ;)
That's the sort of bug dilemma's Microsoft is renowned for, the wine project found many bugs and had to implement them to be compatible with Windows.
Other bugs, like race conditions, lock contention, etc don't break compatibility.
However if we do discover such a bug, I suggest we create an issue on jira for it, with a patch and apply it to the next major release.
As a point of interest, anyone tried running findbugs against river? Cheers, Peter. Niclas Hedhman wrote:
On Sat, Oct 3, 2009 at 1:24 PM, Peter Firmstone <[email protected]> wrote:Ok, how about the following release version scheme? Major.Minor.Point -Point Release: No API changes, bug fixes, internal implementation refactoring only. -Minor Release: Expanded API for existing packages, new utility packages, no breaking of API backward compatibility. Bug fixes, reimplementation or refactoring of existing API functionality. -Major Release: New Features, Packages & API, where those API Changes could potentially break backward compatibility and require recompilation for existing applications. I'm not suggesting we break backward compatibility, just that if we do, it'll definitely be a major point release.Good formulation. Major release "may break either or both of source and binary compatibility"... And then you end up with the problem of defining "when is a bug fix, incompatible change" :-) Ex; If I have the faulty code (excuse me for the silly example); public static int twosComplement( int value ) { return -value; // onesComplement } and the bug fix is; return - value - 1; Is this now a compatible change, a bug fix, since all code using this may break? :-) Fun, heh?? Cheers
