README.Developers

Dear Gyoto developers,

A few notes on maintenance:

Before each commit:
===================

* If you touched configure.ac or any Makefile.am file, run autoreconf
  and commit the regenerated files (configure, Makefile*.in)

* Run make check. If possible, build the yorick plug-in so that
  make-check will do the detailed regression testing suite.

* Check that the files you are commiting have correct Copyright
  information, including the years. If needed, use "git blame
  <filename> to check who modified this file and when.

* Add something in the NEWS file. The NEWS file should contain an
  entry for the next release, put your note in there.

* If this commit changes the user manual, update the date on the title
  page.

To make a new release:
======================

* Check with the team whether they had plans for this release.

* Update the date in the user manual. Check the right date by using
    git log doc/user_guide
  and edit doc/user_guide/GyotoManual.tex accordingly.

* Choose a version number. Version is MAJOR.MINOR.MICRO. Bump MAJOR
  when significant new feature are there; update MINOR for continued
  development of existing features; update MICRO for bugfix or
  packaging releasing.

* Edit configure.ac
  + update the version info in AC_INIT
  + update VERSINFO according to
http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
  Note that this VERSINFO has nothing to do with the Gyoto version.
  + run autoreconf.

* Edit NEWS
  + add a new entry (or change the one which has not been released yet)
  + mark the release either "ABI n" if the ABI changed, "BUG" if its a
    simple backwards-compatible bugfix release, PKG if only the
    packaging has been changed.
  + document shortly what has changed in Gyoto: new features,
    significant bug fixes...

* Regenerate ChangeLog:
  + run "git log --no-merges > ChangeLog"
  + add an item on top which should correspond to the log message that
    you will use for the *next* commit (the one that does the
    release). Use "unknown" as commit identifier and the output of
    "LANG=C date --rfc-822" as date.

* Make clean, configure, make, make check again.

* Commit the changes.

* If releasing another branch than stable: merge this branch into
  stable, make sure the two branches can be merged both ways and are
  identical, merge stable into master.

* Tag the release using the version as tag name. Use a signed tag:
  "git tag -s 1.0.0".

* Take a coffee break.

Coding rules:
=============

Don't use std::atof from cstdlib. Use Gyoto::atof instead. Gyoto::atof
is a wrapper that ensures demical_point is "." and handles special
values like DBL_MAX.

On output (especially to XML), you should also make sure to use the
'C' locale. If using C-style sprintf(), this can be done with:
    #include <clocale>
    std::string loc(setlocale(LC_NUMERIC, NULL));
    setlocale(LC_NUMERIC, "C");
    sprintf(txt, fmt, val);
    setlocale(LC_NUMERIC, loc.c_str());
If using C++-style streams:
    #include <locale>
    std::locale Cloc("C");
    ostringstream ss;
    ss.imbue(Cloc);
    ss << val;

Regards, Thibaut.