scikits-odes-daepack missing 3.1.0 release on PyPi

[moorepants]

Given that all these new packages are managed in this single repository, should we expect that all four packages get the same releases on PyPi? or are mismatches in version numbers expected? For example, all but the daepack PyPi release have a 3.1.0 version at the moment.

[aragilar]

The absence of a 3.1.0 for scikits-odes-daepack is expected. When I have a fair bit of time I will see what I can do to be able to release each project independently, but I don't expect scikits-odes-daepack to have another release unless there are changes to the docstrings or there needs to be changes to the build system again.

I expect future releases of the various packages will be for one of two reasons: new features/refactoring/etc. that is specific to the scikits-odes packages, or needing to make changes to support changes in SUNDIALS.

[moorepants]

Ok, thanks. Will the github tags be in sync with the pypi releaeses then? For example, the repo git tag covers all packages and then only portions of them will be released to pypi, so if I pull 3.1.0 from github I'm actually getting daepack 3.0.0. It's a bit confusing for downstream packaging. There also are no pins in the pyproject.toml files, i.e. should scikits.odes 3.1.0 have a scikits-odes-daepack >= 3.0.0 or == 3.0.0 pin (along with scikit-odes-sundials ==3.0.0)?

[aragilar]

Currently, for all but scikits-odes-daepack, the git tags are the source of truth for where the version is defined (via versioneer). I expect for now the 3.x series to work with whichever versions are installed.

If the PyPI packages are not sufficient for downstream packaging, please file issues and create PRs as needed (I would ideally avoid needing to split the git repo into multiple repos).

[moorepants]

The PyPi packages are sufficient, I'm just trying to understand how the new scheme works so that I can organize it correctly in the Conda Forge package.