Route update/win/version/releases not returning latest release for prerelease versions (alpha, beta, etc)

[djpereira]

I am testing nuts for an Electron-based application. Specifically, I’m checking on the autoUpdater feature that in turns uses Squirrel.Windows. Squirrel.Windows is normally very straight forward as it just uses files, but as I am considering nuts for OSX, and it would be worth using the same framework for Windows too.

Let’s say I have 2 Windows releases 0.1.0-alpha and 0.1.1-alpha.
If I call http://localhost:5000/api/resolve?platform=win&channel=alpha I correctly get my files from 0.1.1 alpha (RELEASE, .EXE and .NUPKG).

The atom feeder looks good too:

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
    <id>versions/channels/all</id>
    <title>Versions (all)</title>
    <updated>2016-03-30T21:27:59Z</updated>
    <link rel="alternate" href="http://localhost:5000/feed/channel/all.atom"/>
    <generator>Feed for Node.js</generator>
    <entry>
        <title type="html"><![CDATA[0.1.1-alpha]]></title>
        <id>http://localhost:5000/download/version/0.1.1-alpha</id>
        <link href="http://localhost:5000/download/version/0.1.1-alpha">
        </link>
        <updated>2016-03-30T21:00:13Z</updated>
    </entry>
    <entry>
        <title type="html"><![CDATA[0.1.0-alpha]]></title>
        <id>http://localhost:5000/download/version/0.1.0-alpha</id>
        <link href="http://localhost:5000/download/version/0.1.0-alpha">
        </link>
        <updated>2016-03-30T20:02:45Z</updated>
        <summary type="html"><![CDATA[This would be the release notes.]]></summary>
    </entry>
</feed>

Given the suggested auto-updater code for Electron:

var app = require('app');
var os = require('os');
var autoUpdater = require('auto-updater');
var platform = os.platform() + '_' + os.arch();
var version = app.getVersion();
autoUpdater.setFeedUrl('http://localhost:5000/update/'+platform+'/'+version);

If I’m running v0.1.0-alpha then the URL would behttp://localhost:5000/update/win/0.1.0-alpha. When it gets to this point, electron will tell Squirrel about this URL, and in turns Squirrel will try to grab “RELEASES” from that URL.

All good until now. However, when I examine the RELEASES content from this call this is all I get:

C0C95B542B50E5C48AE70D92E5C2F733BA32D4BD http://localhost:5000/download/0.1.0/lifesize.cloud-0.1.0-alpha-ia32-full.nupkg 46509055

So once I am in 0.1.0-alpha, I am pretty much stuck, because RELEASES does not contain the latest version (0.1.1).

Am I missing something here or using it wrongly? I’d expect that when I call http://localhost:5000/update/win/0.1.0-alpha?RELEASES I should get the address that points to the latest release.

I am probably wrong, but I was thinking I was going to get something along the lines of:

C0C95B542B50E5C48AE70D92E5C2F733BA32D4BD http://localhost:5000/download/0.1.0/lifesize.cloud-0.1.0-alpha-ia32-full.nupkg 46509055
522DF065733B0F00656530709A96694DC4B19E2E http://localhost:5000/download/0.1.1/lifesize.cloud-0.1.1-alpha-ia32-full.nupkg 46509171

Indicating Squirrel that now there’s a new version that can be downloaded and installed.

[djpereira]

I checked how you work this and you are using node-semver. This is how node-semver treats prerelease tags. From https://github.com/npm/node-semver:

If a version has a prerelease tag (for example, 1.2.3-alpha.3) then it will only be allowed to satisfy comparator sets if at least one comparator with the same [major, minor, patch] tuple also has a prerelease tag.

For example, the range >1.2.3-alpha.3 would be allowed to match the version 1.2.3-alpha.7, but it would not be satisfied by 3.4.5-alpha.9, even though 3.4.5-alpha.9 is technically "greater than" 1.2.3-alpha.3 according to the SemVer sort rules. The version range only accepts prerelease tags on the 1.2.3 version. The version 3.4.5 would satisfy the range, because it does not have a prerelease flag, and 3.4.5 is greater than 1.2.3-alpha.7.

Is there a chance to add an option to use semver.gt instead of semver.satisfies for comparisons? They make very good points in the node-semver github page about why they do this for semver.satisfies. However, in some situations, for a software engineering team that want to subscribe to multiple release channels is parallel (dev, test, production, etc), the "greater than" approach would work better.

[djpereira]

I think PR #52 would fix this issue too.

[fasterthanlime]

I think PR #52 would fix this issue too.

Yup, that's what it solves.