X-Git-Url: http://sjero.net/git/?a=blobdiff_plain;f=ChangeLog.README;h=d50b07821e59805de91f110940f1fcd172eaecc9;hb=b80f38951613e4147bb6828d397430525a2140b8;hp=a90aba4aca0117ccb103e35c077347618a9be51f;hpb=691601f81c6bb95fe4e2e715e021f25bf5fe0a5e;p=wget

diff --git a/ChangeLog.README b/ChangeLog.README
index a90aba4a..d50b0782 100644
--- a/ChangeLog.README
+++ b/ChangeLog.README
@@ -4,35 +4,11 @@ Please note that Wget has more than one ChangeLog file:
                  and to files in subdirectories like po/ that don't have
                  their own ChangeLogs 
 
+    src/ChangeLog: documents only changes to files in the src directory
+
     doc/ChangeLog: documents only changes to files in the doc directory
 
-    src/ChangeLog: documents only changes to files in the src directory
+    windows/ChangeLog: documents only changes to files in the windows directory
 
 When checking to see if a patch you sent in has been applied, please
 look in the appropriate ChangeLog(s).
-
-In addition, you'll notice the ChangeLog-branches directories.
-
-In late 2000, time constraints delayed the release of Wget 1.6.  While
-it was awaiting release, people had new features and other changes they
-wanted added to the CVS archive, but these were deemed not safe to
-introduce just before a release.
-
-The solution was to split the stable 1.6 off onto its own branch, while
-free-wheeling development continued on the main branch (whose version
-was changed from 1.5.3+dev to 1.7-dev).
-
-Unfortunately it's difficult to portray this branched development in the
-flat ChangeLog file.  Either you include 1.6-branch changes in the
-1.7-branch ChangeLog, in which case it becomes impossible to tell what
-release version a given change first went into Wget, just judging by
-date and position in the ChangeLog, or you omit all 1.6-branch changes
-from the 1.7-branch ChangeLog, in which case all evidence of the
-existence of 1.6 (and further information about that branch) disappears
-from future versions of Wget.
-
-The solution that was decided upon was to make a subdirectory called
-ChangeLog-branches adjacent to each ChangeLog file.  Inside is the
-corresponding ChangeLog from the most recent release on the stable
-branch (e.g. 1.6_branch.ChangeLog).  This way, no information is lost
-and there's no misleading information in the ChangeLog.