X-Git-Url: http://sjero.net/git/?p=wget;a=blobdiff_plain;f=ChangeLog.README;h=3a0dbf01d49e41769039221d7c346bb61b28eec8;hp=a90aba4aca0117ccb103e35c077347618a9be51f;hb=HEAD;hpb=691601f81c6bb95fe4e2e715e021f25bf5fe0a5e diff --git a/ChangeLog.README b/ChangeLog.README index a90aba4a..3a0dbf01 100644 --- a/ChangeLog.README +++ b/ChangeLog.README @@ -2,37 +2,15 @@ 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 + their own ChangeLogs 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. + doc/ChangeLog: documents only changes to files in the doc directory -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). + windows/ChangeLog: documents only changes to files in the windows directory -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. + msdos/ChangeLog: documents only changes to files in the msdos directory -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. +When checking to see if a patch you sent in has been applied, please +look in the appropriate ChangeLog(s).