Since we are in the middle of updating OWA SWMM with incoming changes from EPA SWMM 5.2.2, I wanted to bring up the issue of versioning in this software. I think it is important to keep this project up to date with the latest engine from EPA, and since 2020 we have versioned OWA SWMM to match the underlying EPA SWMM engine version (5.1.13, 5.1.14, and 5.1.15). However, binding the OWA SWMM version number to EPA limits the frequency API specific releases. Do we really need to wait for EPA to issue a release for OWA to release new API features for the sake of matching version numbers??
Does the community have any thoughts on this? Two options below:
Should OWA SWMM have two version numbers? One for engine and one for API? How would that look? Would we need to relabel and re-release older versions to have API version numbers
Should we simply add a fourth semantic version (e.g. 5.2.2.0) to indicate updates to the API?
Since we are in the middle of updating OWA SWMM with incoming changes from EPA SWMM 5.2.2, I wanted to bring up the issue of versioning in this software. I think it is important to keep this project up to date with the latest engine from EPA, and since 2020 we have versioned OWA SWMM to match the underlying EPA SWMM engine version (5.1.13, 5.1.14, and 5.1.15). However, binding the OWA SWMM version number to EPA limits the frequency API specific releases. Do we really need to wait for EPA to issue a release for OWA to release new API features for the sake of matching version numbers??
Does the community have any thoughts on this? Two options below:
Should OWA SWMM have two version numbers? One for engine and one for API? How would that look? Would we need to relabel and re-release older versions to have API version numbers
Should we simply add a fourth semantic version (e.g. 5.2.2.0) to indicate updates to the API?
Any other ideas? Does this even matter? 😵