ci(release): reinit release notes, update dist scripts

[wpbonelli]

• reinitialize release notes
• substitute version into folder tree shown in release notes (previously was 6.x.x)
• add OS tag to distribution name substituted into release notes and mf6io
• refactor update_version.py with packaging.version.Version and convert version.txt to plain text
  • consistent with flopy and what Python projects will need to adopt
  • replace "+" suffix indicating dev status with ".dev0" to comply with PEP 440 and allow using Python's built-in versioning utils
• use .mf6minsim for sample mf6 output in build_docs.py instead of ex-gwf-twri01 from ex-gwf-twri.py
• add --repo-owner option to build_docs.py to allow testing on a fork
• add meson.options to full distribution
• fix check_dist.py example script tests: previously expected run scripts to be in top-level example model dir, but some examples have nested subdirs

[mwtoews]

To me, the development version should be 6.4.3.dev0. This would fix the "major" and "minor" positions, and conform to version comparisons ("greater than"). For instance, compare:

from packaging.version import Version

# This is the latest release to compare to
v642 = Version("6.4.2")

v = Version("6.dev4")
print(f"{v.major=} {v.minor=} {v.micro=} {v.dev=} {v > v642}")
# v.major=6 v.minor=0 v.micro=0 v.dev=4 False

v = Version("6.4.3.dev0")
print(f"{v.major=} {v.minor=} {v.micro=} {v.dev=} {v > v642}")
# v.major=6 v.minor=4 v.micro=3 v.dev=0 True

and if you want to get fancy, things like setuptools-scm use git describe for the dev local info based on the git hash. For example 1ce12a2 would be version 6.4.3.dev3+g1ce12a2de0:

from subprocess import check_output

check_output('git describe --dirty --tags --long --match "*[0-9]*"', text=True).strip()
# 6.4.2-3-g1ce12a2de0

v = Version("6.4.3.dev3+g1ce12a2de0")
print(f"{v.major=} {v.minor=} {v.micro=} {v.dev=} {v.local=} {v > v642}")
# v.major=6 v.minor=4 v.micro=3 v.dev=3 v.local='g1ce12a2de0' True

[wpbonelli]

Thank you @mwtoews the hope was less frequent need to change develop branch version numbers but I see it was wrong / out of order. Updated to your suggestion

[wpbonelli]

Would you suggest any way to achieve something like v6.4.2+? Motivation being not to specify the version under development, as it's not known what the next release number will be, but still indicate development has continued?

[mwtoews]

From what I've seen, usually the "next release" is just to increment the micro number, so long as it has something like "dev" in it. The actual version number, when published, can jump up to a major version. Often these decisions are made close to the release, depending on things like big new features or breaking changes.

[wpbonelli]

@mwtoews after discussion it was decided to bump minor instead of micro, otherwise I believe the plan is to adopt your proposed scheme here, flopy and other related repos. Thanks for the guidance here