You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The versioning and workflow are not language-specific, but the mechanics of publication are. Releasing Cladetime will be a good exercise in working out a Python publication process, and we should document that process in the Hubverse docs because:
The Hubverse is planning to develop a Python version of hubData, which will presumably be released on PyPI
The Reich Lab would prefer to use Hubverse release documentation as a reference, rather than maintaining our own process.
@zkamvar What do you think about this? Does it make sense to add Python documentation to an article tied to an R package?
Given that the article for the release process in the hub devs package has no R or quarto-specific features that are not also in readthedocs, we should probably just move the relevant sections here and then keep the R-specific process in the hubDevs package and add a python-specific process to a separate page here, so the structure would look like:
docs/source/developer/
├─ index.md
├─ release-process.md
├─ hotfix.md
├─ r.md # provides link out to hubDevs vignettes
└─ python.md
Background
As the Reich Lab gets ready to release a software package to Python's package index (Cladetime), we're leaning towards adopting the Hubverse release process as designed and documented by @zkamvar.
The versioning and workflow are not language-specific, but the mechanics of publication are. Releasing Cladetime will be a good exercise in working out a Python publication process, and we should document that process in the Hubverse docs because:
hubData,
which will presumably be released on PyPIDefinition of done
hubDocs
is updated as described in this commentThe text was updated successfully, but these errors were encountered: