set app version to 2.0.0 and include v2 features in that case

[jkarneges]

This excludes v2 features when the app's version in Cargo.toml is < 2.0.0. It also sets the version to 2.0.0 so inclusion of v2 features remains the default when building on main. With this behavior in place, we can conditionally produce releases of either v1 or v2 from main and we shouldn't need a separate v1 branch.

There is also a legacy-runner feature flag that controls whether to build a pushpin-legacy binary, which is default enabled as well. This is a separate flag since it's not possible to conditionally build binaries based on the app version. Note that the app version determines the implementation of the main runner; if you set the app version to 1.x but leave the legacy-runner feature enabled, you get two runners that are both the legacy implementation.

To build v1 and avoid producing a redundant pushpin-legacy binary (as a standard v1 release would do), change the version number in Cargo.toml to 1.x and set cargo features explicitly:

CARGO_FLAGS="--no-default-features --features do-qmake,do-cpp-build" make

The way it works under the hood is if the app version is >= 2.0.0, build.rs sets a version_ge_2 Rust cfg attribute as well as a VERSION_GE_2 C++ define, to mean "version greater than or equal to 2". Features are then guarded like:

#ifdef VERSION_GE_2
upcoming_v2_feature();
#endif

Flags are provided instead of actual version numbers since, unlike C++, Rust doesn't have a way to do conditional compilation based on version math, and this keeps things consistent in both languages. However, it should be possible to stack such version flags to do version range checks, which is why they indicate "greater than or equal" rather than exact versions. For example, a hypothetical major version 3 could set a version_ge_3 flag along with a version_ge_2 as well.

[clintjedwards]

You're my hero