Dependabot-core: Option to enable release candidates/beta versions of dependencies

[connorshea]

I don't know if anyone else would actually use this or find it useful, but I think it might be interesting for library developers if they could see compatibility scores of pre-release versions.

For example, Rails 5.2.1.rc1 comes out and it relies on people actually manually installing it in their application and testing to see if any bugs come up. Instead, Dependabot could automatically open a pull request for updating from 5.2.0 to 5.2.1.rc1 and then CI would run for my-rails-app. If I see that it fails, I can look into it and report the issue to the Rails issue tracker. If it succeeds, the compatibility score goes up and the rails core team can publish the release with more confidence it doesn't have any major issues.

Now, for Rails this isn't as useful because some people are running the RCs already anyway. But for smaller libraries I think this could be really interesting.

Some other thoughts I figured I should note:

• Would this actually be useful to library maintainers?
• Would this only be useful in certain circumstances? (e.g. opening a PR for updating from 5.1.0 to 5.2.0.rc1 or 5.2.0 to 6.0.0.rc1 wouldn't be as useful because Rails often has breaking changes even in their minor releases, and new major versions would obviously have breaking changes.)
• Matching beta versions is difficult, different projects use different version identifiers for beta releases and release candidates, e.g. 5.2.0.rc1, 5.2.0-rc1, 5.2.0-alpha1, 5.2.0-beta1, 5.2.0.beta1`, etc.
• Would users actually opt into this setting? If very few people use it, it wouldn't be as useful.
• You'd want to make sure the PR isn't accidentally merged manually, this could probably be fixed by just having dependabot mark the PR as WIP?

[greysteil]

@connorshea - you're one step ahead of me as usual, but I'm super keen on this. It's the next step for compatibility scores / badges: we built out the SemVer stability page with the intention of later adding links to failed CI runs for maintainers, and I've already had feedback from quite a few big dependency maintainers that they'd find it useful.

Next step is for @petehamilton and myself to put together a design for it, and then add the option for users to opt in to having pre-release branches/PRs created on their repos for testing purposes. We'll then link to the results of those CI runs from the expanded SemVer stability page.

[connorshea]

I'm glad we're on the same page, I look forward to it! :D

As always, thank you @greysteil and @petehamilton for dependabot 🙇

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within seven days. Thank you for your contributions.

[mynkow]

What is the relation with dependabot/feedback#451 ?

[andreasohlund]

We, Particular Software, would love to get this feature in since it would allow us to have our downstream projects (60+) always use the latest preview version of our "core" package to quickly catch issues.

Is there anything we can do to help get this feature prioritized?

[andreasohlund]

We actually got a PR raised today for a prerelease, can someone confirm that this is now supported for nuget?

Side note: That also uncovered a bug in the way the bot parses semver 2.0 versions see https://github.com/dependabot/feedback/issues/950

[jmalloc]

We actually got a PR raised today for a prerelease, can someone confirm that this is now supported for nuget?

Piggy-backing on this, I came here trying to find out why a new version of a Go module I tagged as 1.0.0-rc.0 was not causing PRs in that module's dependants. So FWIW it seems it's definitely not supported universally.

[mrbusche]

I'm pretty late to the game, but seems this is not supported for gradle or gradle.kts build scripts either.