Been using Syncthing for years. Started out with it on Linux and moved to macOS last year for some work-related stuff. But I have never paid attention to keeping Syncthing-inotify updated. It was managed by the package managers if I recall.
So… I installed Syncthing and Syncthing-inotify with Homebrew. Now I know I should not have done that because I have Syncthing set to auto-updates itself - and Homebrew continues to try to update it, again.
Why auto-update? Because this has caused a few issues over the last year with my Linux and Windows servers, and windows desktop/tablets all having auto-updated multiple times, which broke replication because my macOS version needed upgrading. They updated to newer versions while my macOS version, auto-update disabled and updating via Homebrew only, did not get the update. I have actually lost a few files because of this confusion (thank goodness for offsite backups): confusion being “Hey, Syncthing auto-updates itself in all shapes and forms across all OSes - except on Homebrew. You do it manually there.”
I think this should be made more clear to those installing via Homebrew. Maybe a large COMMENT block added in the description to the Homebrew package.
That’s not a problem with Syncthing or the package manager. One must be aware that if installing with Homebrew the covenants of this type of install when using Syncthing with other computers, that may have auto-update enabled (which is required to use Syncthing in the first place!).
Anyhoot… I am about to uninstall the Homebrew version of Syncthing and just install the download package manually, which will just let it update itself without Homebrew managing it.
My question is: does the Synthing-inotify have the same auto-update functionality? Or, do I need to keep it under Homebrew package management like normal and just periodically update (once or twice a month)?
Syncthing does not automatically upgrade to an incompatible version.
We don’t manage the Homebrew packaging here, but I don’t think a warning about lack of auto upgrade would be warranted. Homebrew is the thing that manages upgrades of software installed via Homebrew and Syncthing acts exactly the same as everything else in that respect.
[quote=“calmh, post:3, topic:9375, full:true”]
Syncthing does not automatically upgrade to an incompatible version.[/quote]
I think that statement may be misleading though. While it may be true, I think you mean in the context of its own internal state, with the ability to upgrade its own state to be compatible with the next protocol version or metadata upgrade.
I recall two distinct times in the last two years that Syncthing auto-upgraded itself on my desktop and servers, but required all other clients connecting to it to upgrade to continue syncing. E.g. a protocol change, encryption change, metadata upgrade, etc. During this time, my OSX version stopped syncing - for months until I just happened to notice files missing on my desktop that was on my osx - and vice versa. When I looked into it, the servers and desktops were a couple versions newer and syncing; but, my OSX version stopped syncing. The error message in the desktop/server logs was something like an old client was attempting to connect, and rejected with a “Please upgrade” or something.
Unless you are saying i can go download v0.9.12 (cica Sept 2014), install and set it up, and it will work fine with v0.14.23 (released today)? I believe I’d get an incompatible protocol or encryption messaging, asking me to upgrade to continue syncing. Humm, that’d be a good exercise on my commute home one afternoon.
Staying with syncthing first:
All that is said about syncthing auto-upgrading is targeted at syncthing’s own upgrade mechanism. If you use a package manager (apt, yum, homebrew, the arch thing I forgot the name of and many more) this does not apply. In that case it is only up to the packager what you get.
Syncthing does only auto-update to compatible versions, e.g. 0.14.15 -> 0.14.16 but not for incompatible versions, e.g. from 0.13.19 -> 0.14.1.
So no you can’t expect 0.9.12 to work with 0.14.23 but you can expect a group of syncthing instances to keep being able to communicate to each other while auto-updating (again, only if internal upgrade mechanism is used).
The only thing relevant for the compatibility of syncthing-inotify is the Rest API. So in general old versions should keep working, but every now and then there is an upgrade needed of syncthing-inotify when upgrading syncthing. As already said, such an update must be installed manually. The only way to get notified of this as far as I know is to watch the syncthing-inotify github repo.
Ah, that makes more sense. Though an auto-upgrade has prevented other clients from syncing at least twice in the last few years. So that may the policy now; but, that policy has failed at least once in the past.
Agreed with the package manager statements as well - as that is why i am originally posting. Other users though may not be aware - hence, perhaps a warning or suggestion in the Homebrew may help hint to others.
It sounds like I will end up using the Download/Installer version of Syncthing, for auto-updates; but for syncthing-inotify, keep it under package manager updates.
Seems a bit odd; but, that looks to be the safest way.
I should have written that this is the plan. As there are release candidates only since recently, there were instances were breaking bugs made it into releases (but rarely). Now with the release candidate testing, such a scenario is much less likely. And the “last few years” seems like an eternity in terms of syncthing time
Even better the packager should be aware. E.g. for debian/apt there is apt-listchanges notifying about special circumstances on upgrades. However you have to bring that up with the specific maintainer.
The “don’t upgrade to an incompatible version” check was introduced in v0.10.15, December 2014. Since then there have been a couple of issues with auto upgrade but I don’t think an unwanted automatic upgrade to an incompatible version was one of them.
It’s quite easy to press the “upgrade” button inadvertently though. And of course, things distributed via Homebrew, APT, etc don’t follow this policy at all.