New section "Recent history of the project: What version *is* this, anyway?".

Rename section "A brief history of the project" to "Ancient history" and remove
disclaimer about being out of date.

winsup/doc/what.texinfo

@@ -51,10 +51,78 @@ charge a fee for it.  Plus, it provides income for the cygwin project so
 we can continue working on it.  For further details about the commercial
 product, see @file{http://www.cygnus.com/cygwin/}.
 
-@section A brief history of the project
+@section Recent history of the project: What version @emph{is} this, anyway?
 
-@strong{(Please note: This section has not yet been updated for the latest
+Starting on April 17, 2000, the Cygwin team changed the procedure for
-net release.)}
+doing net releases.
+
+Previously, net releases entailed downloading one or two large files
+(called something like @code{FULL.EXE} or @code{USER.EXE}).  These files
+unpacked a "Cygwin Distribution" to a static (and arcane) directory
+structure.  This distribution contained lots of .exe, .a, .h, and other
+files.
+
+These distributions were named after the version of the Cygwin DLL which
+they contained.  The last version released with this method was Cygwin
+B20.1.
+
+This distribution method has the advantage that everything was "all in
+one place".  You could copy the huge FULL.EXE file around and know that
+you were getting the complete "Cygwin Distribution".
+
+The method had several disadvantages, however.  1) it was huge, 2) it
+was hard to download in one error-free piece, and 3) it was hard to
+update.
+
+Why was it hard to update?  Because any change to any package in
+FULL.EXE meant re-generating all of FULL.EXE.  This process was not easy
+to automate since FULL.EXE was an InstallShield executable.  As a
+result, until recently, Cygwin development was relatively static.
+
+To rectify these problems, the Cygwin team decided, early in January
+2000, to break up the packages in the release and make a small program
+(@code{setup.exe}) available to use in downloading packages.  After much
+development and internal discussion on the cygwin-developers mailing
+list, the new, improved version of a Cygwin release was made available
+on April 17, 2000.
+
+This new release also had a new version of the Cygwin DLL -- 1.1.0.
+Most of the other packages were updated and some packages from the
+Cygwin CD were included.  Meanwhile, the Cygwin DLL continues to be
+updated, and is more generically referred to as "1.1.x".
+
+Users obtain this package by first downloading a version of
+@code{setup.exe}.  This program started as a simple command line tool,
+has metamorphosed into a GUI, and is in the process of continual
+improvement.  However, its purpose is simple -- it is designed to
+install packages from the cygwin web site at sources.redhat.com.  In
+effect, it is a smaller, more intelligent replacement for FULL.EXE.  It
+does not require the downloading a huge executable but rather downloads
+individual small packages.
+
+Does this mean that the new net release of the Cygwin package is 1.1.x?
+No.  We no longer label the releases with the Cygwin version number.
+Each package in the cygwin release has its own version now.
+
+Does this mean that Cygwin 1.1.x is newer than B20.1?  Yes!  The cygwin
+1.1.x versions all represent continual improvement in the Cygwin DLL.
+Although the 1.1.x code is still considered "beta quality", the Cygwin
+team felt comfortable enough with the cygwin technology to bump the
+version number to "1".
+
+The other packages in the latest directory are also continually
+improving, some thanks to the efforts of net volunteers who maintain the
+cygwin binary ports.  Each package has its own version numbers and
+its own release process.
+
+So, how do you get the most up-to-date version of cygwin?  Easy.  Just
+download the setup.exe program from your closest mirror.  This program
+will handle the task of updating the packages on your system to the
+latest version.  The Cygwin team frequently updates and adds new
+packages to the soureware web site.  The setup.exe program is the
+easiest way to determine what you need on your system.
+
+@section Ancient history of the project
 
 The first thing done was to enhance the development tools (gcc, gdb,
 gas, et al) so that they could generate/interpret Win32 native object