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
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
