Developer Documentation
=======================

This document contains specific instructions for HARP developers.

Commit steps
------------
If your changes impact any of the autogenerated parts, make sure these
get regenerated (all using the autotools build system):

Run 'make doc' to regenerate the documentation.
Current versions used for generating the documentation are:
- Sphinx 3.3.1
- sphinx-autobuild 2020.9.1
- sphinx-rtd-theme 0.5.1
- breathe 4.25.1
- doxygen 1.8.20
The full list of third party dependencies can be found in `doc/requirements.txt`

Run 'make dist' to have config.h.cmake.in and harp.h.cmake.in updated to be
in line with config.h.in and harp.h.in.

Make sure that python/_harpc.py gets updated with any change to harp.h.in.
This should happen automatically using the Makefile dependencies.
But, make sure to do this by performing an in-source build of HARP such that
the _harpc.py file in the python subdirectory of the source tree gets replaced.
Current versions of cffi and pycparser for generating the python interface are:
- cffi 1.7.0
- pycparser 2.14

Run 'make indent' using GNU indent (2.2.11) to update the indentation of the C
code. You may have to run it twice to work around flipping indentation choices
of GNU indent.

Release checklist
-----------------
- update embedded versions of expat, netcdf3 and udunits2 if needed
- make sure all 'commit steps' (see above) have been performed
- ensure automake and CMake builds are consistent
- check compiler warnings
- increase HARP version number in configure.ac + CMakeLists.txt +
     doc/conf.py (version + release)
  format version is x.y(.z).
  Increase x for big backward compatibility breaking changes.
  Otherwise, increase y if any features were introduced.
  Only add/increase z for bug fix releases.
- update HARP format version if needed (configure.ac + CMakeLists.txt)
  format version is x.y (major.minor version).
  major version increases are for changes in the structure:
  - basic data types
  - attribute names and data types
  - dimension names
  minor version increases are for changes in the content conventions:
  - variable naming
  - ascending/descending contraints
  - dimension ordering
  so (x+1).* routines will usually need a modified reading routine to read x.*
  and x.(y+1) routines should be able to map from x.y after reading a product
  there is no forward compatibility, so higher versions will always be rejected
- update version number of shared libharp library (both in configure.ac and
  CMakeLists.txt)
- make sure all documentation is updated accordingly
- update README (version number at top)
- update CHANGES

Conventions
-----------
- Don't use a starting capital letter or terminating period for warning/error
  messages. Treat messages as something that could be included between
  parentheses as part of a larger sentence. Try to stick to a single sentence
  for a message. If you have to use multiple sentences then separate them with
  a semicolon.
- The same capitalization/punctuation rule for messages also applies for
  descriptions used in product ingestions.
