Ecosystem maintenance guide #7
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Member
jeromekelleher
left a comment
jeromekelleher
left a comment
There was a problem hiding this comment.
Generally looks good, but it needs some human intervention (the em-dash at the start was an immediate giveaway!). The ideas are a bit muddled and need more consideration.
Can you break long lines here also please.
|
|
||
| ### Releases | ||
|
|
||
| Release preparation follows the approach documented for tskit (see https://tskit.dev/tskit/docs/latest/development.html#releasing-a-new-version). Before tagging, review the changelog and ensure it includes only user‑visible changes: public API additions/removals, behavior changes, deprecations, and significant bug fixes. Internal refactoring, CI plumbing, and formatting changes should not appear in release notes. |
Member
There was a problem hiding this comment.
This will confuse people as the tskit release process is an outlier. I think we need to separate out the standard Python tagging process using setuptools_scm from thinngs like tskit where it's manual.
|
|
||
| Release preparation follows the approach documented for tskit (see https://tskit.dev/tskit/docs/latest/development.html#releasing-a-new-version). Before tagging, review the changelog and ensure it includes only user‑visible changes: public API additions/removals, behavior changes, deprecations, and significant bug fixes. Internal refactoring, CI plumbing, and formatting changes should not appear in release notes. | ||
|
|
||
| Git tags trigger the wheel build and test workflows. Python packages use tags of the form `vX.Y.Z`. In tskit there is also a separate C API release flow. The release workflow drafts a GitHub Release with the appropriate changelog content and build artifacts. On tag push, CI builds the sdist and wheels for each supported platform and runs import/smoke tests against the built artifacts. When the release notes are correct, publish the Release on GitHub. If a repository uploads to PyPI on “release published”, the action handles the upload; otherwise, build locally with `python -m build` and upload with `twine`. |
Member
There was a problem hiding this comment.
How do you know if the repo uploads to pypi?
|
|
||
| Git tags trigger the wheel build and test workflows. Python packages use tags of the form `vX.Y.Z`. In tskit there is also a separate C API release flow. The release workflow drafts a GitHub Release with the appropriate changelog content and build artifacts. On tag push, CI builds the sdist and wheels for each supported platform and runs import/smoke tests against the built artifacts. When the release notes are correct, publish the Release on GitHub. If a repository uploads to PyPI on “release published”, the action handles the upload; otherwise, build locally with `python -m build` and upload with `twine`. | ||
|
|
||
| After a release, update dependent repositories where necessary. For example, if the C API version changes in tskit, dependent projects such as msprime, tsinfer, pyslim, and the Rust bindings need to be checked and bumped as required. Conda‑forge feedstocks are maintained for these packages (for example, tskit’s feedstock: https://github.com/conda-forge/tskit-feedstock); the conda-forge bot usually opens PRs after a PyPI release. Verify the version, checksums and dependencies, then merge the feedstock PR once CI is green. |
Member
There was a problem hiding this comment.
Conda forge is separate and not to do with dependent repos, this is confusing. Should have a separate section describing the release artifacts and where they go
| Repositories use pre‑commit for linting and formatting, and the configuration is intentionally similar across projects. Periodically update hooks with `pre-commit autoupdate`, then run `pre-commit run --all-files` locally to refresh generated changes. Commit the hook updates and any resulting formatting changes together in a single PR. We standardise on `clang-format` 6.0 for cross‑platform compatibility. | ||
|
|
||
|
|
||
| ## Tskit Ecosystem Meetings |
Member
There was a problem hiding this comment.
This is for a different document I think.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@jeromekelleher I'll link to this from the website ecosystem page.