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]