send PRs for pre-releases if the project already uses a pre-release version

[travi]

this thought was sparked by #518, but is, in a way, a request to also go down the opposite path than is described in that issue. if i'm already using a pre-release, i'd love to get a PR when a newer pre-release version is published. i agree that PRs should not be sent when the project is using a stable version, but if i've made the decision to use the pre-release, being upgraded to the latest would be very helpful.

[gr2m]

I wonder if there is a clear definition of what a pre-release is? Packages published with a dist-tag different than @latest? Version numbers with a - like 9.0.0-1? Is there any standardisation around it?

I think it would be cool to be able to subscribe to dist-tag release other than @latest, that’s something I could see Greenkeeper support in the future.

But if someone releases 9.0.0-1 with dist-tag @latest then you’ll get the update from Greenkeeper, it’s by design, and I don’t know who we would work around it. The correct "fix" would be that the author would use a dist-tag like @next or @beta or @rc

[travi]

I think my intent is for non-latest channels. I'm looking for additional PRs rather than less, but i would only want them if I'm already consuming a pre-release version. I could see determining that to be the harder part since it could change.

I agree that this might not be straight forward, but happy to talk through options and trade-offs if we want it to move forward.

[gr2m]

i would only want them if I'm already consuming a pre-release version

this could be hard to determine without extra configuration. Say you have version ^2.0.0 defined which is currently released to npm with @next while @latest points to 1.2.3. If the author now sets @latest to also point to 2.0.0, then we no longer know that your intent is to subscribe to beta releases. If the next day the author release 3.0.0 using @next, who would Greenkeeper know that you want to receive an update for it?

[travi]

Yep, that's the complexity that i meant. Configuring my project to subscribe to nextwouldn't be ideal either, for exactly the scenario you just described. I would have opted into the choice to use next, but with the assumption of switching to stable, once promoted. I would want to opt in again before getting pre-releases of 3.0.0

[travi]

Scenarios that I'm thinking about are situations like the long running beta of webpack 2, or react hot loader 3. If i opted in because i wanted the features early, i'd want to switch to stable once those were promoted without staying on the beta channel forever.

[absolutehype]

I've got this issue right now, and it's causing some pretty undesirable behaviour https://github.com/expressjs/express/releases

I just received an update for greenkeeper/express-5.0.0-alpha.6.

I'm currently running 4.15.4 and their current release is 4.15.5. Shouldn't I be receiving an update to 4.15.5 rather than their pre-release (being a major version bump)?

[travi]

@absolutehype that sounds more like #518. i agree with @gr2m that the problem is that they released their prerelease as @latest, but i think that issue is the one to follow discussion around whether greenkeeper could be more helpful if the maintainer isn't following the correct process.

[gr2m]

I just received an update for greenkeeper/express-5.0.0-alpha.6

They released express@5.0.0-alpha.6 with the latest and since set latest back to 4.15.5. This seems to happen quite often recently, we should probably add an additional check for versions that don’t look like x.y.z version ...

Scenarios that I'm thinking about are situations like the long running beta of webpack 2, or react hot loader 3. If i opted in because i wanted the features early, i'd want to switch to stable once those were promoted without staying on the beta channel forever.

I the best solution would be to support version numbers in the ignore settings, so you could add "webpack@>2" if you want to keep the update checks for 2.x.x releases but ignore 3.xx releases

[travi]

Is there any standardisation around it?

for true semver pre-releases, the required format is <version (#.#.#)>-<preid>.increment. its expected that when a pre-release defined like this is intentionally promoted to latest, that the -<preid>.increment is removed. this seems fairly straightforward to check for.

we should probably add an additional check for versions that don’t look like x.y.z version

you probably could simplify to this, but i'm not sure if there are other cases than the <version (#.#.#)>-<preid>.increment format that are allowed by npm's strict adherence to semver that don't follow the #.#.# format. i don't know if being generic or specific in this case is more helpful for this goal.

I the best solution would be to support version numbers in the ignore settings, so you could add "webpack@>2"

i agree that configuration is probably the best bet for cases that still follow the #.#.# pattern. the ignore config is probably the shortest path to enabling this from the current state, but i think handling it with package.json semver ranges would be simpler and potentially more intuitive