Define device-flexible @sync

[charleskawczynski]

This PR defines a device-flexible @sync.

[Sbozzolo]

The change looks good and reasonable to me.

However, shouldn't we bump the minor version as opposed to the patch since we are introducing a new feature (in a backward compatible way)?

(I am assuming we are using semantic versioning)

[charleskawczynski]

However, shouldn't we bump the minor version as opposed to the patch since we are introducing a new feature (in a backward compatible way)?

We're still in pre 1.0, where minor versions are only for breaking changes.

[Sbozzolo]

However, shouldn't we bump the minor version as opposed to the patch since we are introducing a new feature (in a backward compatible way)?

We're still in pre 1.0, where minor versions are only for breaking changes.

Doesn't this break the compat of downstream packages?

For example, ClimaAtmos has ClimaComms = "0.5" in its compat, which is equivalent to [0.5.0, 0.6.0). However, that would be the incorrect interval if ClimaAtmos used ClimaComms.sync.

I encountered this problem with CLIMAParameters. ClimaAtmos declares to be compatible with CLIMAParameters = "0.7", but in reality using anything below 0.7.22 fails.

If our policy is that minor versions are only for breaking changes for 0.X, shouldn't we be more specific in the compats of downstream packages?

[charleskawczynski]

Doesn't this break the compat of downstream packages?

No, ClimaAtmos will be able to work with this new version, since we've not broken other existing features. ClimaAtmos will need to update its dependencies to leverage using ClimaComms.@sync.

I encountered this problem with CLIMAParameters. ClimaAtmos declares to be compatible with CLIMAParameters = "0.7", but in reality using anything below 0.7.22 fails.

This is a local problem, and is fixed by using Pkg.resolve

If our policy is that minor versions are only for breaking changes for 0.X, shouldn't we be more specific in the compats of downstream packages?

I'm not sure I follow, but if you look at ClimaCore releases, for example, many new features have been added and we've not updated the minor version in a long time (we're on version = "0.10.52").

EDIT: we don't need to be more specific in the compats because the next version number (the patch version) is non-breaking

[Sbozzolo]

This is a local problem, and is fixed by using Pkg.resolve

When it comes to Pkg, this is not a problem: ClimaAtmos declares that it is compatible with CLIMAParameters in [0.7.0, 0.8.0), so Pkg doesn't see any problem with me having version 0.7.19. In the same spirit, as a user, when I read 0.7, I assume that anything in the 0.7.X series would work. However, ClimaAtmos is not really compatible with versions [0.7.0, 0.7.21]. If you run with any 0.7.X version of CLIMAParameters that is not 0.7.22, ClimaAtmos would fail for mysterious reasons. On the other hand, if we were to declare that ClimaAtmos depends on CLIMAParameters > 0.7.21, Pkg would see that I have the incorrect version and pull the new one.

I'm not sure I follow, but if you look at ClimaCore releases, for example, many new features have been added and we've not updated the minor version in a long time (we're on version = "0.10.52").

I argue that the ClimaCore has same problem. ClimaAtmos declares to be compatible with ClimaCore 0.10.0, but it won't work unless you use the latest version.

The Pkg docs say:

pre-1.0 version with non-zero minor version (0.a.b with a != 0) is considered compatible with versions with the same minor version and smaller or equal patch versions (0.a.c with c <= b); i.e., the versions 0.2.2 and 0.2.3 are compatible with 0.2.1 and 0.2.0

So, Pkg treats all the versions with 0.5.X as being interchangable. The docs go along saying:

In particular, a package may set version = "0.2.4" when it has feature additions compared to 0.2.3 as long as it remains backward compatible with 0.2.0.

So, downstream dependencies that use ClimaComms.@sync should declare 0.5.5 in their compat instead of 0.5. Similarly, every time any new feature in any package is used (e.g., a new parameter in CLIMAParameters), the compat should be updated to require the minimum version.

[charleskawczynski]

While I agree with some of your points, e.g.,

So, downstream dependencies that use ClimaComms.@sync should declare 0.5.5 in their compat instead of 0.5.

That is unrelated to this PR. If you feel that this is a system-wide issue, can you please open a PR in our polices repo?