Issues related to API and backwards compatibility

[PaulWessel]

Description of the desired feature

We made some changes to the API after it was first introduced in 5. To avoid any backwards compatibility issues we added code like this, e.g. at the end of the struct GMT_DATASEGMENT definition:

#ifdef GMT_BACKWARDS_API
	double **coord;
#endif

since we had briefly used the variable coord for what we now uniformity call data. There are a few like that in gmt_resources.h. I do not know if there are anyone whose code would break if we removed this. However, for 6.x there may be new things that requires a backwards compatibility. The GMT_STR16 (value 16) was a dumb name and I will need to increase it to 32 and introduce a new constant called GMT_VF_LEN = 32 instead. The GMT_STR16 will be kept but set to 32 as well.

Question: Perhaps GMT_BACKWARDS_API need to be more version-specific. Maybe it should be GMT_API_V5 and my new change could go under GMT_API_V6.0 or something?

[joa-quim]

I think we should not worry much with backward compat for the API. One thing is to try to maintain backward compatibility with all those GMT4ever guy's scripts. Another thing is the API. By going to a major version number change all programmers should know that compatibility issues may arise. It's the SEMVER law.

[seisman]

By going to a major version number change all programmers should know that compatibility issues may arise. It's the SEMVER law.

Totally agree.