Also - if I modify electron-release-server to return only newer editions, the app throws an error (could not parse empty release file).

@tkambler thanks for using the app. I'm sure there are still bugs to work out here and there. Your help in identifying them is much appreciated. Before we start, I'd like to make sure that you're publishing your app with the save version name as the one in your package.json. Let me know.

When you say "publishing" - what are you referring to? Certainly not npm publish. Are you referring to the file name that I'm uploading to the release server?

My project structure looks like this:

app
    -> package.json
        {
            "name": "assessments",
            "productName": "Assessments",
            "version": "1.0.0"
        }
package.json

It's built with electron-builder. The following file is created: assessments-1.0.0-full.nupkg

I sign into the release server, click "Add a New Version," enter 1.0.0 as the version name, select the stable channel, and click upload.

@tkambler Version 0.2.0 contains numerous fixes, one of which relates to the RELEASES file. Let me know if you still experience this issue :)

Windows works beautifully now - thanks! Unfortunately - OS X is now broken, which was working fine for me before.

• I create v1 of the app.
• I upload the .zip to the server.
• I launch the app - no updates are found (as expected) - the app runs normally.
• I quit the app.
• I create v1.0.1 of the app.
• I upload the new zip for v1.0.1 to the server.
• I launch the original version of the app on my computer. An update is found and downloaded. The app quits. I launch the app again - the update has not actually occurred. I'm still at v1.0.0, rinse and repeat. Endless loop of updates.

FYI... In my previous attempts at using this (during which time, OS X seemed to be working fine), I was uploading the .dmg file and not the .zip. This time, however, I am uploading the .zip and not the .dmg, because the server (for good reason? I don't know?) filters out any non-zip assets in the controller.

I'm about to strip that part out and serve up dmgs again and will see what happens.

Serving up DMGs was a failure, going back to ZIPs. Possibly important: after the download of the updated ZIP has occurred, quitAndInstall() is called. At this point - according to Electron's docs - the app is supposed to restart itself once the update has finished. This does not occur. I have to manually launch it again myself.

Also - if I manually download the updated .zip from the server, unpack it, and run the resulting .app myself - it is obviously the newer version that I want.

This may be unrelated to the release server - I'm having the same problem seen here.

Hi @tkambler, thanks for testing this.

I'm glad to hear that Windows support has been repaired.

DMGs should only be provided to the user for initial installation, that is why the release server filters out non-zip files for the update process.

I'll look into this myself and see what I come up with.
Are you sure that the zip is being downloaded properly?

Things seem to be working now. The issue was with improper permissions set on Squirrel log files contained within ~/Library/Application Support/com.electron.... Resetting those fixed the issue. As to how that happened in the first place... ?

Excellent, glad to hear. Let me know if you have any other issues or suggestions.

@ArekSredzki - Frustratingly, I am again actually dealing with this issue.

Question - In the VersionController - why does the OS X endpoint query for versions > the date of the version of the requestor, while the Windows endpoint queries for versions >= the date of the version of the requestor?

@tkambler On OS X the server is supposed to return any new releases that are available. That said, on Windows, because it uses a hash, you can return the current version as well. By using the hash, it can ensure that it is on that same version.

Would you mind elaborating on the issue that you are having?

I'm seeing an endless loop of upgrade installs. See original description from two days ago. And I have some more clues. I'm creating a 32-bit version of the app - that's the only one I'm uploading to the release server. I'm installing the app on a 64-bit machine. I'm doing some debugging on the local machine - particularly the process by which the update info is fetched.

Crucially - when the update has been downloaded, I'm comparing the local version as reported by my app with the version of what was just downloaded. They do not match, based on a disparity b/w architectures. The local app reports its version as 1.0.0 - while the downloaded update has a version of 1.0.0-ia32 - resulting, it would seem, in an endless loop of installs.

• Does this issue occur if both 32bit and 64bit versions of the app are uploaded?
• This is on OS X, yes?

Windows. There is no such thing as a 32-bit OS X Electron app. Am about to go back to creating both 32 and 64 bit versions. Will report back. I don't think this should be necessary though...

Of course, I wasn't thinking.

I think that this will be resolved by using strict platform matching when resolving update endpoints.

That way the 64 bit version will not see the update if one does not exist for that arch.

We wouldn't want 64 bit versions "downgrading" themselves to 32bit anyway.

I'll push an update after lunch.

Deploying both 32 bit and 64 bit versions of the application seems to solve the issue. I'll do that for now. It would be nice though if this problem could be solved. It's not always necessary to deploy both... sometimes 32 bit is sufficient.

@tkambler Fixed in 81d51de

@ArekSredzki Endless install loop bug is back with this update (0.3.0).

http://bitcubby.com/files/skitch/Vagrant_-_Windows_10_1CCA6840.png

I'm at version 1.0.0 of the app (the only version, which I have also uploaded to the release server). When the app launches, it fetches the list of available updates from the release server. Note the difference between the version that is reported by the release server and the version that the app sees itself as having (1.0.0 vs 1.0.0-ia32).

@ArekSredzki I have a CI server that generates these builds for me. For the 32 bit build, the generated file looks like this:

assessments-1.0.0-ia32-full.nupkg

For the 64 bit build, the generated file looks like this:

assessments-1.0.0-full.nupkg

This problem seems to go away so long as I strip the -ia32 suffix from the 32-bit build's filename, making it look like the 64 bit build.

Ugh, no - that doesn't fix it. I'm falling back to dual builds (32 / 64).

@ArekSredzki If you don't have a good environment in which to replicate this, look me up on Freenode - channel #electron-release-server and we can step through this together.

@tkambler I'll hit you up on there, but this is a usage issue. If the install is x64 then it should ask for win64 not win32

@tkambler I don't see you in that room.

https://dl.dropboxusercontent.com/u/832215/Screenshots/Screen%20Shot%202016-04-22%20at%209.45.49%20AM.png

Skype? tkambler

Try IRC again. Should work now.