------------------
Purenum 0.4e alpha
------------------
VERSION
------------------


RELEASE HISTORY

version  state   changes
-------  ------  -------

  0.4e   alpha   major bugfix to the wide multiplication code (fastmul code)
                 general optimizations and bugfixes
                 added a divmod() function for fast quotient and remainder

  0.4d   alpha   added class Array for easy multidimensional, resizable arrays
                 cleaned up the string functions a bit
                 added math library style functions pow(), fac(), etc.
                 minor interface tweaks for the Rascal project

  0.4c   alpha   added Integer_GMP, Integer_fake, and Integer_fakeu classes
                 the makefile now can switch between the different Integer
                 variants by typedefing the selected one to the new Int type

  0.4b   alpha   renamed project to "Purenum" from simply "Integer"
                 "wide" operations now all work and are reasonably fast
                 demo program 'testinteger' now shows a variety of bignum tests

  0.4a   alpha   all "thin" operations work pretty well now
                 "wide" multiplication and division are extremely slow
                 demo adds 4000000000 to 1000000000 correctly, but very slowly
                 internal representation is now in the correct ALU base
                 (this is the first public release)

  0.3    alpha   added optimized "thin" operations, this gives a major speed
                 increase because the most common cases are processed inline
                 instead of behind function calls

  0.2    alpha   simple ability to add and subtract now working
                 internal representation is decimal for easy testing

  0.1    new     initial version of CLASS INTEGER


RELEASE NUMBERING SYSTEM

Whole version numbers are stable versions.  Version numbers with low fractions
are alpha quality, high fractions are beta quality.  Bugfix releases add a
single lowercase letter after the version number.

This numbering system tracks real releases to users.  Internal revisions on
large projects are probably better tracked by a higher resolution system such
as build numbers, mapping that system to this one for the users benefit.

The value of this system is that normal users only have to care about simple
numbers.  "Version 1" or "version 2b" is easy to remember for most people.
Also, people are most encouraged to upgrade to stable releases because it is
easy to remember that a new whole number represents software which has already
been well-tested in alpha and beta phases.  The "alpha", "beta", and "stable"
status of the software can be determined directly from the version fraction
going thru ten steps:

    x      stable (same as x.0)
    x.1    major new untested features (probably all broken)
    x.2    alpha quality (major new features)
    x.3    alpha quality (major new features)
    x.4    alpha quality (major new features)
    x.5    final alpha test (bugfixes only)
    x.6    beta quality (minor new features)
    x.7    beta quality (minor new features)
    x.8    beta quality (minor new features)
    x.9    final beta test (bugfixes only)
    y      new stable version (x+1, same as y.0)

This outline does not need to be strictly followed but as close as possible.
It is for the benefit of users or customers, try not to confuse them.

In an x.5 version all major features (all major advertising points) should be
present and working.  By the x.9 version all known desired features should be
complete.  This is the final release candidate.  Version y.0 will ideally
be identical to version x.9 but with all bugs squashed.

If bugs are fixed in a whole number release a single lowercase letter will be
appended to the fixed version number.  For alpha and beta versions the letters
can indicate bugfixes and/or new features.  The first release of each version
fraction has no letter, so for example there is version 0.1 followed by up to
26 other versions named 0.1a thru 0.1z.

Remember for the choice of version number the only thing that matters is
communicating the state of the project to the user.

