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.
This commit is contained in:
David Starks-Browning 2000-09-12 13:00:10 +00:00
parent a887d79dab
commit 267ca95b4d
1 changed files with 71 additions and 3 deletions

View File

@ -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
net release.)}
Starting on April 17, 2000, the Cygwin team changed the procedure for
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