chore(main): release 2.0.0 #164
Conversation
| setup( | ||
| name="science-synapse", | ||
| version="2.3.4", | ||
| version="2.0.0", |
There was a problem hiding this comment.
thats a great question, im unsure. the only thing i did to fix the autodeploy to pip was put in fresh PYPI_TOKEN and RELEASE_PLEASE_AT entries in this repo's secrets, i'll investigate
There was a problem hiding this comment.
Initial investigations:
- it is tagged at 2.0.0 because .release-please-manifest.json contains 1.0.1. It then automatically scans prefixes of commit messages for patterns such as "fix" "feature" "chore" etc. (more specifically, using the convention specified in https://www.conventionalcommits.org/en/v1.0.0/) to decide how to bump the version. Prefixes containing a "!" (which indicates a breaking change) or BREAKING CHANGE will bump the major version ( https://github.com/googleapis/release-please). Additionally, it will accumulate these bumps until someone merges the automatic release-please PR (such as this one). So, there has been exactly one of those prefixes since the last release-please merge (or, since it was set up).
- Once a release-me PR has been merged, it will automatically tag our repo with the release version. This tagging will then trigger .github/workflows/release.yml, which will trigger deployments to TestPyPi and ultimately PyPi for pip deployment. In general, git tags will trigger deployment to pip.
- However, I'm a little confused since I don't see any merged release-please PRs in our closed PR history. Additionally, release-please was set up by Antonia and Gil in this commit: 1d80c6a with version number 1.0.1, but it was then never touched. Merging release-me PRs should automatically update this.
My current conclusion is that it was set up but no one put in a working Github PAT for this repo's secrets::RELEASE_PLEASE_AT (thus, not triggering release-please PRs), and that deployment was handled by manually "git tag"ing.
We can proceed either by manually git tagging every time we want to release to pip (which is what I imagine Gil was doing, evidenced in my next paragraph), or by manually updating .release-please-manifest to our current version, closing this PR, and then following the conventional-commit standard for commit messages from this point forward. Either way, we should close this PR.
However, this is inconsistent with the fact that CHANGELOG.md was previously updated many times, including to 2.0.0 which is what this PR is specifying, with formatting consistent with release-please. My suspicion is that CHANGELOG.md was updated by some manual tool that only Antonia used since CHANGELOG.md was only ever modified by Antonia. Then, I imagine Gil was unaware of this/didn't want to use it, and just deployed to pip manually by manually git tagging, never updating CHANGELOG.md.
There was a problem hiding this comment.
the title of this PR reflects a lack of attention to the whole premise here... anyone who uses synapsectl should know that we have been past 2.0.x for a while. how did this get created at all?
There was a problem hiding this comment.
It was automatically generated by release-please when you merged your commit to main. It was set up by Antonia in April of this year: 1d80c6a It is under my name because I renewed the RELEASE_PLEASE_AT secret in this Github repo with my Github PAT since the old one expired. It contains incorrect versioning + changelog information because it was set up, but seemingly no one was using it after it was set up, likely due to a quickly stale PAT put into the RELEASE_PLEASE_AT field in this Github's secrets.
If you want, I can make the changes to get release-please working (automatic tagging + automatic changelog updating through parsing commit messages) with the correct version number, or I can remove my PAT from RELEASE_PLEASE_AT to disable it, and instead we tag + deploy manually with "git tag" (that appears to be what Gil was doing, though there would be no CHANGELOG.md).
There was a problem hiding this comment.
Got it, will do: I'll be closing this PR and removing all of the release-please hooks/configs from this repo. Note that from now on if you ever want to deploy a release to pip, you can simply do
// First, update the version in setup.py manually
git tag v.x.y.z
git push --tags
I'll remove CHANGELOG.md too since it appears to only be an artifact of release-please/[whatever tool Antonia was using to automatically generate it] for human visitors of this repo. All of the historical information currently in it can be gathered from Antonia's commit history in this repo.
🤖 I have created a release beep boop
2.0.0 (2026-01-11)
⚠ BREAKING CHANGES
Features
get_last_sync_time_nsto TimeSyncClient (#102) (90a7ffc)Bug Fixes
This PR was generated with Release Please. See documentation.