Upgraded to 13 and now my two nodes wont connect

Right y’all, sounds like something I encountered right after I upgraded yesterday. The issue was that while Syncthing has been updated to v0.13 and v0.13.1 with new protocols across the board, several of the “side projects” that accompany Syncthing have not yet been released with the new protocols. Many projects on Github and other software update and release new versions of all their core software simultaneously, but that’s not the case with Syncthing. So far, v0.13 protocol and other changes have broken compatibility with accompanying software (GUI wrappers, discovery servers, etc.) so setups with multiple parts (not using default public servers, etc.) have been broken. However there are no newer working releases yet published to fix these incompatibility issues. In the case of the discovery servers, this is confounded a little bit by the fact that v0.13 may appear to indicate that registration with a global discovery server was successful even when it wasn’t when speaking with older discosrv software, making identifying this incompatibility issue harder. The /v2/ which was appended during the upgrade process is not well documented in docs because no newer v0.13‐compatible software has yet been released in the discosrv project (so there’s nothing to document there yet).

As a result, to fix the incompatibility issue with private global discovery servers, you can either avoid upgrading for now until an official v0.13‐compatible version is released or else run a non‐release discosrv while you wait. This can be achieved either by building it yourself or by checking the build server.

Now that we pushed all our devices to v.0.13, we’re not going back.

Wish we knew that there wasn’t a released discosrv yet before we pulled the trigger. In the interim, I chose to fallback to the “default” discovery servers, and we’ll wait it out.

@Atacama raises some good points - to which I would add the following suggestion: Keep the main Syncthing application in pre-release mode until all the associated components are ready to roll. This might slow things down, but the offsetting benefit will be a reduction in reported broken clusters.

Thanks.

1 Like

Just grab the latest build: there’s nothing particularly special about releases for discosrv.

Exactly, it’s just gets tagged, but the version in the build server is the version that is running on the public servers.

You’d think this is easy, but people have real life arrangements, and are located in different timezones, so it’s impossible to get everyone to do things at the same time. We though all components are ready to roll, but shit happens and bugs appear.

Thanks. I looked through that and the upgraded-to-v0.13 version of it, but can’t see anything wrong there at least.

There is now a new “release” of the discovery server.

Obviously you don’t agree, but I actually think we managed this fairly well this time. It’s probably the most well coordinated “major” release we’ve ever done. We’ve had betas out for months and heads up on the upcoming release for weeks, and compatibility "ACK"s for the Android and Synctrayzor wrappers.

We didn’t have a published binary for the discovery server, but there is one now and it’s a fairly small minority of users who run their own. Those who do run their own infrastructure like that would probably be well served in keeping up to date with the beta program, for that matter, or delay upgrading to a new incompatible release until things have definitely shaken out.

The docs are always lagging, but we are a small team and bugs / features do get prioritized a little - you can all help here if you like.

In the end, we’re not a single cohesive entity. The various wrappers and side projects are all maintained by different people on different schedules in different stages of their lives, voluntarily. Frankly, I’m amazed this shit works as well as it does.

If we were to wait for all contributions to be compatible, we’d never get to release anything. :wink:

2 Likes

First off, thanks to you and Audrius and the other contributors. You guys put out some stellar stuff and it really is an extremely useful product. I think what NickPyz was getting at was that because Syncthing is precisely so useful and ends up being like a backbone for many clusters, internal company projects, and other such things, continual running stability (not necessarily protocol stability, etc.) is really one thing that many Syncthing users would like. Obviously, as upgrades happen, new versions have to break compatibility, and that’s fine. Syncthing is so useful that it’s spawned a great deal of dependant software, and it really is impossible to go around waiting for all of it to be updated. But (without trying to put too many words in Nick’s mouth) when the core products necessary for running a cluster are updated, it might be best to update at least these few as a unit (Syncthing+discosrv+relaysrv). These three are provided by you and Syncthing is never released without working public discovery servers, for instance, so the code to make it happen is already there and working. Just in this case, it hasn’t been released at the same time, so some people who upgraded part of their setup found that based on the publicly available releases they could not continue to run their system properly without downgrading or dabbling with unreleased software.

Now when I encountered this issue I just pulled changes from the repo and made it work, no big deal. But many people rely on the releases exclusively and won’t use unreleased software in a production environment. I know at least a couple people who’ve performed upgrades only to realize that they could only upgrade Syncthing and not discosrv effectively breaking their clusters. Just for situations like that I might agree with Nick’s suggestion that for the core components, they should stay in pre-release/beta mode until they can all simultaneously be released and updated through “traditional” channels (as opposed to manual building or downloading from build servers). Just a suggestion. In my case, it wasn’t a terrible problem, and I resolved the issues within a couple hours. But I might back up Nick’s suggestion for future consideration when dealing with “core” syncthing+discosrv+relaysrv. Cheers.

1 Like

Hi, I am not sure what to do, my pc and my seedbox don’t see each other, my pc is v0.13.1, Windows (64 bit) and the seedbox is v0.12.23, Linux (64 bit).

As noted in the release notes, v0.13 is not compatible with v0.12.

When will there be a v0.13 for linux or what solutions could I implement so long?

Of course, v0.13 was released for Linux at the same time as for everything else.

okay, thank you, sorry for my blondness, I will see with my seedbox provider why we don’t have the new version

Or you can just download it from github and at the same time be assured of future stability updates. :slight_smile:

There’s no disagreement here. I acknowledge that the team is small. And at the same time, I stand in awe at how productive the dev. team is at pushing out such a high volume of new features and bug fixes.

For users who are using St to create a cluster of personal devices (I am one such user), time delays and occasional cluster crash is understandable - given the resources situation you described.

However, where Syncthing is used in a production environment and connects devices owned by multiple people (I am also a user in this situation) - it’s messy. A cluster break because some auxiliary component isn’t released (discosrv or Android for example) is harder to repair - and sometimes remote peers want to abandon Syncthing for some other solution.

Not sure if there is a simple solution - but until there is, let’s accept that the onus is on users to verify that all the required pieces are released before executing a version upgrade - especially where the new version is incompatible with the previous one.

Thanks.

EDIT: Forget to mention that the new discosrv v0.13 solved our disconnects issues. Thanks for the quick rollout!

I think the confusion stems from here: just because noone’s created a GitHub release for discosrv, does not mean that a version for 0.13 does not exist. Indeed, the very start of the README says “To get it, run go get github.com/syncthing/discosrv or download the latest build from the build server.”

Both of those approaches will have given you an up-to-date discosrv, from before Syncthing 0.13 was released.

Again, discovery server support for Syncthing 0.13 was available long before Syncthing 0.13 was released.

You won’t have seen it, but a lot of coordination went on between the maintainers of different third-party components (including the Android wrapper), and 0.13 was only released when everyone gave the thumbs-up. Any delay in releasing a new Android version is then the sole responsibility of the maintainer of the Android wrapper (who is a third party).

1 Like

Yup, you are correct.

I believe it falls apart when a user (someone naive like me :heart_eyes:) opens the web-GUI and sees that glittery upgrade button. It’s tempting to click on it before looking at a README file, or checking that all the required pieces are released.

Also, my peers in a production environment will not permit beta components inside the cluster. That’s not a Syncthing problem, it’s just something my peers and I have to manage better.

There’s a huge red warning dialog that pops up, warning you that all of your devices (and, by extension, discosrv, etc) need to be upgraded as well :smile:

2 Likes

You mean we’re actually supposed to read that stuff? :dizzy_face:

A post was split to a new topic: Not able to select folders

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.