version: combine NM_VERSION_CUR_STABLE and NM_VERSION_NEXT_STABLE
We don't need to have two version defines "CUR" and "NEXT". The main purpose of these macros (if not their only), is to make NM_AVAILABLE_IN_* and NM_DEPRECATED_IN_* macros work. 1) At the precise commit of a release, "CUR" and "NEXT" must be identical, because whenever the user configures NM_VERSION_MIN_REQUIRED and NM_VERSION_MAX_ALLOWED, then they both compare against the current version, at which point "CUR" == "NEXT". 2) Every other commit aside the release, is a development version that leads up the the next coming release. But as far as versioning is concerned, such a development version should be treated like that future release. It's unstable API and it may or may not be close to later API of the release. But we shall treat it as that version. Hence, also in this case, we want to set both "NM_VERSION_CUR_STABLE" and again NEXT to the future version. This makes NM_VERSION_NEXT_STABLE redundant. Previously, the separation between current and next version would for example allow that NM_VERSION_CUR_STABLE is the previously release stable API, and NM_VERSION_NEXT_STABLE is the version of the next upcoming stable API. So, we could allow "examples" to make use of development API, but other(?) internal code still restrict to unstable API. But it's unclear which other code would want to avoid current development. Also, the points 1) and 2) were badly understood. Note that for our previousy releases, we usually didn't bump the macros at the stable release (and if we did, we didn't set them to be the same). While using two macros might be more powerful, it is hard to grok and easy to forget to bump the macros a the right time. One macro shall suffice. All this also means, that *immediately* after making a new release, we shall bump the version number in `configure.ac` and "NM_VERSION_CUR_STABLE".
Showing with 14 additions and 12 deletions