Abstract -------- Every Husky project should contain *two* files that serve the purpose of documenting development progress. ChangeLog is autocreated from cvs log messages. So provided sensible info when requested to enter a log message when doing "cvs ci". HISTORY must be created manually by you. Only put important things for users into this file The ChangeLog file ------------------ The file named "ChangeLog" should reside in the root directory of the project. This file documents every single thing that developers do. It is important for developers, but contains much too much information for normal users. The ChangeLog file can be created automatically by the CVS server from CVS log messages if you like. In order to tell the CVS server to auto-create the ChangeLog file, your project must contain the files ChangeLog and .cvs2cl in the project root. The contents of these files do not matter, they simply must exist. I.e., you should do touch .cvs2cl ChangeLog cvs add .cvs2cl ChangeLog cvs ci ChangeLog .cvs2cl in your project root directory to tell the cvs server to auto-create the ChangeLog file. The CVS server will then overwrite the ChangeLog file with a change log based on CVS log messages every night at 23:45 Central European Time / Central European Summer Time. From this follows that whenever you check in a change, and be it only a small bugfix, with "cvs ci", you should enter a sensible log message - users will later see those exact messages you type in there in the ChangeLog file! Currently you are still allowed to omit the log messages, but in the future we will probably disallow such checkins. The HISTORY file ---------------- This file is used to tell users the major things that change between versions, i.E. only documents new features, very important bug fixes and the like. We suggest to call it "HISTORY", but you can also call it "UPDATING" or "WHATSNEW" if you have a strong feeling that this is better. You should make an entry in this file - when you add a new feature - when you fix a non-trivial, non-cosmetic bug that was in the last release, i.E. a bugfix that is serious so that users should really want to have it. - especially important: whenever you change the behaviour of a program or configuration option that was already in the last release and that will require users to modify their configuration when updating to the current source You should *NOT* make an entry in this file - when you fix a bug that was not yet in the last release. Users usually upgrade from release to release and are NOT interested in "fixed a bug that I introduced a month earlier" type info. Or if they want to know it, they can read ChangeLog instead :-). - when you fix a trivial / cosmetic bug, probably one that users did not even complain about. A single entry "fixed several cosmetical bugs" for each release is enough to account for all such fixes. Mirroring at http://husky.sf.net/cvs2 ------------------------------------- If module contains file .nocvs2ftp, this module will not be tarred and put on www mirror. It is useful for example for modules test, homepage and some unused/freezed modules. [EOF]
