Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion .release-please-manifest.json
Original file line number Diff line number Diff line change
@@ -1,3 +1,3 @@
{
".": "1.0.1"
".": "2.0.0"
}
24 changes: 24 additions & 0 deletions CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,30 @@

All notable changes to this project will be documented in this file. See [standard-version](https://github.com/conventional-changelog/standard-version) for commit guidelines.

## [2.0.0](https://github.com/sciencecorp/synapse-python/compare/v1.0.1...v2.0.0) (2026-01-11)


### ⚠ BREAKING CHANGES

* add SpikeDetector, SpikeBinner nodes to client; remove SpikeDetect node from client and server

### Features

* add `get_last_sync_time_ns` to TimeSyncClient ([#102](https://github.com/sciencecorp/synapse-python/issues/102)) ([90a7ffc](https://github.com/sciencecorp/synapse-python/commit/90a7ffcb4e889d79a0d2fbe1127a6f2fa2186f82))
* add SpikeDetector, SpikeBinner nodes; remove SpikeDetect node ([#99](https://github.com/sciencecorp/synapse-python/issues/99)) ([2a6c029](https://github.com/sciencecorp/synapse-python/commit/2a6c02919dc87e96d410a41f8761919922d6604b))
* add TimeSyncClient ([#101](https://github.com/sciencecorp/synapse-python/issues/101)) ([9f89ee3](https://github.com/sciencecorp/synapse-python/commit/9f89ee33a37cd18447aced3d2b023ec738be803b))
* Fix issue where uri is forgotten ([#104](https://github.com/sciencecorp/synapse-python/issues/104)) ([c84a88a](https://github.com/sciencecorp/synapse-python/commit/c84a88a949bec74c57f532696148b952de6434f7))
* populate synapse_api_version DeviceInfo field in server ([#94](https://github.com/sciencecorp/synapse-python/issues/94)) ([20b0aea](https://github.com/sciencecorp/synapse-python/commit/20b0aeaf37776c9aebdca9420172cca13f87184f))


### Bug Fixes

* configure iface ip for local test ([#148](https://github.com/sciencecorp/synapse-python/issues/148)) ([be02b14](https://github.com/sciencecorp/synapse-python/commit/be02b14818a779cd04acd0413e35d6b969a50fe3))
* fix issue with LogLevel type annotation on certain client device methods ([#105](https://github.com/sciencecorp/synapse-python/issues/105)) ([e0bc439](https://github.com/sciencecorp/synapse-python/commit/e0bc439b7df613abbad87e7039ce18636a501170))
* increase timeout for discovery ([#149](https://github.com/sciencecorp/synapse-python/issues/149)) ([6228713](https://github.com/sciencecorp/synapse-python/commit/62287135098fc7de7c64957a157688611c66ae05))
* synapsectl deploy issues with dependency: rich ([#154](https://github.com/sciencecorp/synapse-python/issues/154)) ([c1201db](https://github.com/sciencecorp/synapse-python/commit/c1201db781d8dc635c6266237563983a99b5c18d))
* Update paths for NWB compatibility ([#123](https://github.com/sciencecorp/synapse-python/issues/123)) ([3ae1970](https://github.com/sciencecorp/synapse-python/commit/3ae1970be69e238054f06c4c6407334216e478d8))

## [2.2.0](https://github.com/sciencecorp/synapse-python/compare/v2.1.0...v2.2.0) (2025-05-01)


Expand Down
2 changes: 1 addition & 1 deletion setup.py
Original file line number Diff line number Diff line change
Expand Up @@ -26,7 +26,7 @@

setup(
name="science-synapse",
version="2.3.4",
version="2.0.0",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why does this decrement?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

@calvinleng-science calvinleng-science Jan 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Initial investigations:

  1. 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).
  2. 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.
  3. 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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

@calvinleng-science calvinleng-science Jan 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh. let's disable this.

Copy link
Contributor Author

@calvinleng-science calvinleng-science Jan 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

description="Client library and CLI for the Synapse API",
author="Science Team",
author_email="team@science.xyz",
Expand Down