[svn] ChangeLog.README: Renamed from README.branches and added a note that Wget has

multiple ChangeLog files (currently ./ChangeLog, doc/ChangeLog, and
src/ChangeLog), since this is unusual and people have complained their patches
hadn't been applied after checking only the top-level ChangeLog.

diff --git a/ChangeLog b/ChangeLog
index 42d9cc12334addb310d2915cb441dece6f22760b..39f86ebb67578cf1f9986447e62270c768fad025 100644 (file)
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2001-03-01  Dan Harkless  <wget@harkless.org>
+
+       * ChangeLog.README: Renamed from README.branches and added a note
+       that Wget has multiple ChangeLog files (currently ./ChangeLog,
+       doc/ChangeLog, and src/ChangeLog), since this is unusual and
+       people have complained their patches hadn't been applied after
+       checking only the top-level ChangeLog.
+

 2001-02-28  Dan Harkless  <wget@harkless.org>
 
        * MACHINES: Explicitly tell people to send us config.guess output.
 2001-02-28  Dan Harkless  <wget@harkless.org>
 
        * MACHINES: Explicitly tell people to send us config.guess output.

diff --git a/ChangeLog.README b/ChangeLog.README
new file mode 100644 (file)
index 0000000..a90aba4
--- /dev/null
+++ b/ChangeLog.README
@@ -0,0 +1,38 @@
+Please note that Wget has more than one ChangeLog file:
+
+    ./ChangeLog: documents changes to files in the top-level directory
+                 and to files in subdirectories like po/ that don't have
+                 their own ChangeLogs 
+
+    doc/ChangeLog: documents only changes to files in the doc directory
+
+    src/ChangeLog: documents only changes to files in the src 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.

diff --git a/README.branches b/README.branches
deleted file mode 100644 (file)
index 5f9cabb..0000000
--- a/README.branches
+++ /dev/null
@@ -1,23 +0,0 @@
-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.