Go module path for syncthing/lib remains at v1 — unable to import v2

Hi everyone,

I’m running into a problem with Go module versioning after the Syncthing v2 release.

From what I can tell, the module path in the repository is still declared as:

module github.com/syncthing/syncthing

— meaning it doesn’t include a /v2 suffix.

Because Go requires a versioned import path for major versions ≥2 (for example, github.com/syncthing/syncthing/v2), I can’t import or update to Syncthing v2 using standard Go tooling. This makes it difficult to depend on the latest version of syncthing/lib in other Go projects.

I’m one of the developers of VolSync which uses Syncthing as one of its replication backends. I’d like to understand how we should handle this transition — whether the syncthing/lib library will remain supported for external use, or if it’s now considered internal-only.

So my questions are:

  1. Is there a plan to update the module path to github.com/syncthing/syncthing/v2 so that Go can properly import v2?

  2. Will syncthing/lib continue to be supported as a public library API, or is it intended for internal use only going forward?

  3. If it’s not going to be versioned or supported as a public dependency, we’ll likely need to adjust how VolSync interacts with Syncthing — but it’d be helpful to know the intended direction before we make those changes.

Thanks for clarifying — it’ll help me understand how to approach future integration with Syncthing v2.

Imho lib had never been intended or supported for public consumption and it’s a historical accident that it’s not called internal. I’ve proposed migrating it previously, and new packages have been added under internal instead of lib, but we didn’t in order to avoid breaking things unnecessarily. If everything is now broken anyway we might as well complete the move to make it obvious…

Its not completely broken. I found this project sushitrain/SushitrainCore/go.mod at main · pixelspark/sushitrain · GitHub where he went around by using a pseudo-version that points to a specific commit instead of a proper tag in his go.mod

Yeah for Synctrain I just go get -u github.com/syncthing/syncthing@abcdef (where the latter is a commit hash for a release).

There were some discussions about the status of this interface before. My understanding is that it is not an official API (which means I need to fix if it changes, probably fork if it goes away altogether). I would advocate cleaning it up (and am also willing to assist) but not remove it (as, well, my app is relying on it :)) Some functions were already moved to the ‘Internals’ interface to at least limit apps poking around in Syncthing somewhat.

1 Like