search

NOAA-OWP / t-route

Tree based hydrologic and hydraulic routing
Other
44 stars 50 forks source link

Address Versioning Differences Between Repository and Sources/Artifacts #845

Open robertbartel opened 1 month ago

robertbartel commented 1 month ago

Although the repository itself has a formal version scheme (currently on 2.4.0) used for releases and tags, this doesn't connect properly to the contained sources or built artifacts (i.e., Python package and Fortran modules). Version values that are being used for the artifacts don't appear to have been maintained, and the process for that isn't well documented.

Current behavior

The individual Python packages use there own independent values for versions. These are explicitly set either within the pyproject.toml or __init__.py file of each package. Right now, despite the repo itself having released 2.4.0, the packages are set as:

nwm_routing            0.0.0
troute.config          0.0.3
troute.network         0.0.0
troute.routing         0.0.0

[!IMPORTANT] There is, however, an apparent reference to version 2.4.0 in src/troute-network/troute/nhd_network.py, so this issue probably qualifies as a bug.

@deprecated(version='2.4.0', reason="Functionality moved to Network classes")

I also didn't see anything in a makefile or CMakeLists.txt in the sources for the Fortran module indicating any versioning was being used. Being less familiar with Fortran, it's possible there is something I missed, though nothing that specifically references 2.4.0.

Expected behavior

With the source code for the repo producing multiple, somewhat independent artifacts, it's not immediately clear whether it is more appropriate to version them identically (i.e., they all should be at 2.4.0 right now) or independently (but not at 0.0.0). Other repos with multiple nested packages (e.g., ngen-cal, DMOD) have versioned them independently, but the packages' relationships with each other and to the core purpose of their repository seem different here than for those other repos. Independently versioned packages may also require the existing version scheme for tags and releases to be modified.

More discussion is needed on what approach is best. Regardless, the approach needs to be consistent and clearly documented, and current versions should be updated to something other than 0.0.0 that is consistent with any @deprecated usage.