Develop version 2.1-dev.0 breaks ABI compatiblity

[hellkite500]

trafficstars

The accepted inclusion of get_bmi_version in #111 moves BMI from version 2.0 to version 2.1-dev.0.

By adding this to function name to the namespace, it will break ABI compatibility for all compiled headers in the supported languages (C, C++, Fortran). For example, if a model builds against version 2.1, but some other model/utility is built with version 2.0, the runtime behavior of using the two together is likely to lead to undefined behavior and segmentation faults.

I haven't seen this inclusion land on the implemented interfaces for the various languages yet, but I'm wondering if this should land in a major (non-backwards compatible) version, like BMI 3.0 instead?

[mdpiper]

This seems reasonable. Since we're working with an interface, we should be extra careful with how we do versioning (and how we follow the semantic versioning guidelines). Perhaps we should make it a policy that any time we include new functions in a version, the major version has to be incremented?

[aaraney]

@mdpiper, introducing new functionality is not a breaking change so I think a minor bump is merited. Changes to the existing api would constitute a major version change.

Edit: im wrong. given the way that the BMI is specified, this breaks ABI like @hellkite500 noted. This would have to be a major version bump.