GROMACS

Gerrit received a related patchset '1' for Issue #2764.
Uploader: M. Eric Irrgang (ericirrgang@gmail.com)
Change-Id: gromacs~master~Ib0b1e4408250748dd41356894eb482917e669f0c
Gerrit URL: https://gerrit.gromacs.org/8711

Eric Irrgang wrote:

Target: master branch, post release-2019 split.

Many planned changes for the GROMACS 2020 development cycle will be incompatible with GROMACS 2019 and gmxapi 0.0.7. Some changes will affect previously unspecified behavior. I.e. the specified API will not necessarily change, but behavior will.
(Note, we do not intend to provide standard semantic versioning compatibility guarantees until at least gmxapi 0.1)

• Bump the version in master to 0.0.8 so that clients can distinguish expected behavior while we work on a more formal 0.1 spec.
• gmxapi-config-version.cmake continues to use the SameMajorVersion template for GROMACS 2019, gmxapi 0.0.7, and 0.0.8 to allow client code the decision of whether to handle multiple versions or not.

CMake¶

Since we do not guarantee compatibility between 0.0.7 and later, should we expressly use the ExactVersion compatibility template in CMake? I haven't checked yet whether there is a conventional CMake pattern to first try a find_package for one version and then try again for alternative versions.

See also:
https://cmake.org/cmake/help/v3.4/module/CMakePackageConfigHelpers.html#generating-a-package-version-file

ExactVersion seems the appropriate thing to specify at this time. I don't think there is such a pattern, so we'd have to try to find one version, and then try the other.

Mark Abraham wrote:

ExactVersion seems the appropriate thing to specify at this time. I don't think there is such a pattern, so we'd have to try to find one version, and then try the other.

The client code will need to be updated to allow integration testing for both release-2019 and master. I will update this issue and propose the CMake patch once that is done. Reference https://github.com/kassonlab/gmxapi/issues/188