Update to sofa 18

[mhvk]

A new SOFA release is out. Things run well, but I'd appreciate a check on the new version numbers. For this purpose, SOFA adds 3 new functions, so definitely not just a bugfix, but it also does:

A rearrangement of the ANSI C header files sofam.h and sofa.h has been implemented. The consequence of this is that an explicit #include "sofam.h" has been added to many of the SOFA functions. Thus developers of applications that use constants from sofa.h will now need to include an explicit #include. Further explanation is given in the changes.pdf files included in the distributions.

Even though strictly no symbols changed, since this means people may have to change source code to explicitly include erfam.h if they use the ERFA library, I've interpreted this as implying we should go to a new major version number, i.e., 2.0.0. Does this make sense? (see also the change to README.rst in the second commit: 3939e0d)

For the library proper, the new functions imply a new revision, but it is backwards compatible, so I increased age as well.

p.s. Would have been nice to go to ERFA 1.8 for SOFA 18, but o well!

[mhvk]

To confuse the question about version further, http:https://www.iausofa.org/current_changes.html, states:

The consequence of the change for developers is that any application that uses constants from sofa.h will now need an explicit #include <sofam.h>. It should, however, be noted that the contents of sofam.h are not formally part of the SOFA API, and so such an application is vulnerable to future changes. Rather than adding an #include <sofam.h> to applications, it would be better to replicate the needed macros in the user code.

Frankly, this statement seems somewhat bizarre, as sofam.h includes definitions of physical and astromical constants, some of which might well change (and surely are better used than copied!).

[sergiopasra]

To confuse the question about version further, http:https://www.iausofa.org/current_changes.html, states:

Frankly, this statement seems somewhat bizarre, as sofam.h includes definitions of physical and astronomical constants, some of which might well change (and surely are better used than copied!).

Perhaps they mean that the macros are somehow private to SOFA and they shouldn't be used?

[mhvk]

I think they are thinking about some of the macro functions, like ERFA_DINT. Anyway, I guess we should make our own decision. Certainly, we expose the constants in pyerfa...

[mhvk]

@sergiopasra, @eteq - do you think version 2.0.0 is appropriate here? I'd like to get this in so I can do the pyerfa release as well...

[sergiopasra]

@sergiopasra, @eteq - do you think version 2.0.0 is appropriate here? I'd like to get this in so I can do the pyerfa release as well...

Given that we consider the macros in erfam.h part of the API, yes, that's the version according to sermver. On the way forward, we should stop considering the macros part of our API, removing line 148 here:

erfa/RELEASE.rst

Lines 141 to 149 in 52218f4

	Package version number
	----------------------
	Semantic versioning dictates how to change the version number according to
	changes to the API of the library. In the case of ERFA the API is:
	* The public C macros defined in erfam.h
	* The names, return types, number of arguments and types of the functions in erfa.h

[mhvk]

@sergiopasra - yes, by removing the sentence about the macros we would align ourselves with SOFA. I'm not 100% sure we should do that, but thank you for pointing to what our current contract is: I think this indeed settles the question for this release.

So, let me make that release and start a new issue about whether we should remove the sentence that the macros in erfam.h are part of the API... See #85