As the main developer of the Syncthing for macOS wrapper I would like to know if we could push the v2 as main version and abandon the v1 for auto-updates. I think only bugfixes will be ported between version unrelated major index db change. Let me know what the roadmap is, or if there is a roadmap written down somewhere. When agreed I know if I can push a override from v1 to v2 for mac users automagically (via Sparkle updater framework). People are unable to downgrade (by design). Also if there are some extra changes in the pipeline for v2.1.x then i’m not hurrying to push out this major version upgrade (just yet).
Thanks all for the hard work and making this possible.
I don’t know precisely what you mean by this, but I think this is what we’ve done, more or less.
Further v1 releases will be in case a significant problem (probably security) is discovered and we need to roll out an update. v2 is definitely the “main” version.
I have reflected almost same branch naming in the syncthing-macos sub-project but make use of develop/release branch naming. v1 “release train” is now currently on develop/release and v2 is now just in “pre-release” mode. I still want to make sure its “a little more mature”, waiting until v2.1.x is out and then abandon v1 and swap out release branch for v1 and v2 branch for develop/release. Hope this clears things up.
Frankly, not entirely. Your branching is your branching, I think what matters more is what is provided to users in terms of downloads and upgrades. Syncthing v2 is the thing we link to on the download page and what I think every new install should be. Upgrades are still not automatic for a couple of reasons, mostly that there are some behavior changes and it can take a while, so springing it as a surprise on people will probably not be widely appreciated.
I do think it’s important that there is a way for people who run syncthing-macos to get on 2.0 as we’ve been providing that upgrade path everywhere else for a couple of weeks. Waiting for 2.1, whenever that may be (really a factor of when a new feature triggers the versioning bump), doesn’t necessarily seem like a good criteria to me.
At the same time, I do not think you should auto upgrade v1 users to v2 at this time. Probably still not when release a 2.1. Maybe this is not possible to reconcile with the point above in your upgrade framework? It also wasn’t in for example the Debian/API packages, so we publish v2 there as a separate component which can be intentionally upgraded to, but is not an automatic upgrade.
This answers my question, but in a better way then expected. I will maintain for now two versions then. Need to figure out how I can mark things pre-release in the Sparkle update framework. I know it is possible. As indeed v1 is proven technology, still we need to iron out v2 and get more runtime hours and adoption. Thanks for the response.
How will syncthing on Homebrew be handled? Will we have two packages? Does the DB migration runs automatically when upgrading to v2, or are there any manual steps necessary? I remember I’ve seen some migration guide, but I can’t find it anymore. I wish to upgrade to v2 via Homebrew soon.
You’re in a tough position because you don’t want to automatically (and silently) opt users into v2.x. I get this. The consequence of that, unfortunately, is that it means there’s no obvious path forward short of staying paralyzed or doing UI work to give users a choice and then try to make that work.
My personal opinion is that you need to keep this simple for yourself so that the project is manageable. I depend on it, and I’m sure many other people do, too. I understand this is challenging but my recommendation is to just move to v2 in the main branch. Rip off the bandaid, as they say.
I directly and indirectly manage a number of machines that run the MacOS version using your distribution. It’s time to get these machines on v2. I need the users of those machines to not have to think about this migration and I actually believe that if you just auto migrate them with an update, it’ll work fine.
The other option, which appears to be that the complexity of the problem just leaves us on 1.x indefinitely is worse.
Do you guys have a sense of how big the installation has to be where this starts to be a factor? Or what’s big about it? Is it number of files, number of hashes blocks, number of folders, number of connected devices, etc.
Judging from the reports we’ve had so far, we’re talking about installations consisting of hundreds of folders/devices, and terabytes worth of data.
I would say the limiting factor is number of files and blocks in a given folder. (Large numbers of folders and devices can also suck, but did so prior to the change to SQLite)
All good, I was worried because of potential manual steps, but I learned the database migration is automatic, local online and the protocol stays compatible. DB migration went smooth and everything works. Great project.
All and only issue I met is related to the drop of support for single dash options mainly --no-console, one time --no-browser were it should not be set in the GUI (Windows ~server~ were ST starts on boot)
@calmh and others - syncthing-macos is the sanctioned, turnkey macos release. It’s a fundamental asset and it’s stuck on the August 1.3 build with no sign of progressing. Are you in a position to give it a nudge or to help figure out the go-forward path?
It’s a separate project under our umbrella, run by that project’s maintainers, chiefly @xor-gate. I think that currently it would be good to default to v2 for all new installations, as we’ve done with the “core” downloads for quite a while.
Thanks Jakob, would you suggest to keep the current appcast xml upgrade URL and push v2 macOS bundle when working appropiate ? Or keep both versions seperate and separate installs with two update channels and manual upgrade needed? I didn’t catch up yet on the v2 release train for the official macOS bundle, i was just waiting for v2 to settle out a bit. And I had some life things to catch up past 6 months.
So for the others in this topic, the official Syncthing for macOS “bundle” is not death, but v1 is stable and working as expected. I know people want to hop on the newer versions, but its not always necessary. Never touch a running engine so to say. Thanks for the heads up. Hope Q1”26 I will catch up and see which direction i will push official Syncthing for macOS bundle forward. Feel free to discuss some suggestions. Please use topic https://forum.syncthing.net/t/syncthing-for-macos/ for the sub-project discussions.
Your branching is your branching, I think what matters more is what is provided to users in terms of downloads and upgrades. Syncthing v2 is the thing we link to on the download page and what I think every new install should be. Upgrades are still not automatic for a couple of reasons, mostly that there are some behavior changes and it can take a while, so springing it as a surprise on people will probably not be widely appreciated.