doc(platforms): inform more clearly about best-effort

This has been the case for Windows as well, and is now
made official.
Certain tests already fail on windows, for example.

3 files changed, 7 insertions, 27 deletions

diff --git a/doc/source/index.rst b/doc/source/index.rst
index 1079c5c7..69fb573a 100644
--- a/doc/source/index.rst
+++ b/doc/source/index.rst
@@ -9,7 +9,6 @@ GitPython Documentation
    :maxdepth: 2
 
    intro
-   whatsnew
    tutorial
    reference
    roadmap
diff --git a/doc/source/intro.rst b/doc/source/intro.rst
index 1c1b0d1b..1766f8ae 100644
--- a/doc/source/intro.rst
+++ b/doc/source/intro.rst
@@ -15,7 +15,7 @@ Requirements
 
 * `Python`_ 2.7 or newer
     Since GitPython 2.0.0. Please note that python 2.6 is still reasonably well supported, but might
-    deteriorate over time.
+    deteriorate over time. Support is provided on a best-effort basis only.
 * `Git`_ 1.7.0 or newer
     It should also work with older versions, but it may be that some operations
     involving remotes will not work as expected.
@@ -75,6 +75,12 @@ codebase for `__del__` implementations and call these yourself when you see fit.
 Another way assure proper cleanup of resources is to factor out GitPython into a
 separate process which can be dropped periodically.
 
+Best-effort for Python 2.6 and Windows support
+----------------------------------------------
+
+This means that support for these platforms is likely to worsen over time
+as they are kept alive solely by their users, or not.
+
 Getting Started
 ===============
 
diff --git a/doc/source/whatsnew.rst b/doc/source/whatsnew.rst
deleted file mode 100644
index e0d39b09..00000000
--- a/doc/source/whatsnew.rst
+++ /dev/null
@@ -1,25 +0,0 @@
-
-################
-Whats New in 0.3
-################
-GitPython 0.3 is the first step in creating a hybrid which uses a pure python implementations for all simple git features which can be implemented without significant performance penalties. Everything else is still performed using the git command, which is nicely integrated and easy to use.
-
-Its biggest strength, being the support for all git features through the git command itself, is a weakness as well considering the possibly vast amount of times the git command is being started up. Depending on the actual command being performed, the git repository will be initialized on many of these invocations, causing additional overhead for possibly tiny operations.
-
-Keeping as many major operations in the python world will result in improved caching benefits as certain data structures just have to be initialized once and can be reused multiple times. This mode of operation may improve performance when altering the git database on a low level, and is clearly beneficial on operating systems where command invocations are very slow.
-
-****************
-Object Databases
-****************
-An object database provides a simple interface to query object information or to write new object data. Objects are generally identified by their 20 byte binary sha1 value during query.
-
-GitPython uses the ``gitdb`` project to provide a pure-python implementation of the git database, which includes reading and writing loose objects, reading pack files and handling alternate repositories.
-
-The great thing about this is that ``Repo`` objects can use any object database, hence it easily supports different implementations with different performance characteristics. If you are thinking in extremes, you can implement your own database representation, which may be more efficient for what you want to do specifically, like handling big files more efficiently.
-
-************************
-Reduced Memory Footprint
-************************
-Objects, such as commits, tags, trees and blobs now use 20 byte sha1 signatures internally, reducing their memory demands by 20 bytes per object, allowing you to keep more objects in memory at the same time. 
-
-The internal caches of tree objects were improved to use less memory as well.