1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
|
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 of the documentation tools used for generating the
documentation can be found in the conda-forge environment file that is
located in `doc/environment.yml`
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.15.1
- pycparser 2.21
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.
|
