GameFrame for Java 0.9.4 Class Library
Game Developer Documentation - Version History


Version 0.9    04. Jul  1999 by Pasi Keränen, javanerd@geocities.com
Version 0.9.1 02. Nov 1999 by Pasi Keränen, javanerd@geocities.com
Version 0.9.2 29. Nov 1999 by Pasi Keränen, javanerd@geocities.com
Version 0.9.3 02. Apr 2000 by Pasi Keränen, javanerd@geocities.com
Version 0.9.4 16. Jul  2000 by Pasi Keränen, javanerd@geocities.com


1. VERSION HISTORY

0.9.4 BETA - Fifth BETA release.

 

0.9.3 BETA - Fourth BETA release.

 

0.9.2 BETA - Third BETA release.

WARNING: gameframe.Sound is now named gameframe.Sample. gameframe.Sound contains a new interface different from that in the previous version! When starting to use this version of GameFrame for Java first rename all Sound definitions in your old source code to Sample.

 

0.9.1 BETA - Second BETA release for collecting input from the public.

 

0.9 - Preview release released for collecting input from the public.

 

0.0 - Initial development version, not released to public.


2. ABOUT VERSION NUMBERING

Major version number will be incremented by one upon each new public stable release that will change existing functions in a major way or adds major new functionality. Major versions might break downwards compatibility, but are don't always do that. Breaking downwards compatibility must always be done in a major version update and must be well documented. Backwards compatibility should be preserved for as long as possible.

Minor version number will be incremented by one upon each new public release that adds (or changes in a minor way) functionality to the library's interfaces. This means versions that are bug fix versions or include new engine implementations for the existing interfaces. Upon new major version release this version number will be reset to 0. The game shouldn't need to check for minor version, as minor versions are compatible between each other as far as the interfaces go. But if you know that you use a feature in the library that was fully functional only after a certain minor release, you can check that the library's minor version meets your requirements. The game should always check for "at least version" as the game library should be downwards compatible inside the same major version.

Build number is incremented by each build. One minor version can have (theoretically) up to 2147483647 builds (that is the limit of the used integer number). A build is considered being a compiling of edited source code that is given to person/persons outside the development team. This means that there is no need to count the number of compiles inside the development team.

Unstable build flag is also used when the version in question is a build in anticipation for the next major version, but is not of release quality yet. This usually happens, when a radically new version of the library is underway. E.g. all versions before the first release 1.0.0 are versions 0.9.x with the unstable flag set.

All this means that:


Copyright ©1999-2000 Pasi Keränen, javanerd@geocities.com
Re-use with the GameFrame for Java library builds
allowed if the history field in the beginning of the
document is left intact (only adding of entries
 is allowed, no removing).