Bower should not install a pre-release version if a non-pre-release version is available

[btford]

Current behavior

Let's say jQuery has the following versions:

1.0.7
1.2.0-rc1

If you bower install jquery without specifying a version, the release candidate (1.2.0-rc.1) is installed by default.

Preferred behavior

Below is a table of the available versions for a given package versus the version bower installs by default, when no version is specified (i.e. bower install foo).

Available Versions	Bower Installs
{ 1.0.7, 1.2.0-rc.1 }	1.0.7
{ 1.0.7, 2.0.0-rc.1 }	1.0.7
{ 1.2.0-rc.1 }	1.2.0-rc.1
{ 1.2.0-rc.1, 1.2.0-rc.2 }	1.2.0-rc.2
{ 2.0.0-rc.1, 1.2.0-rc.2 }	2.0.0-rc.1

Rational

Users of Bower should expect to get stable packages by default. This is especially important in reducing the amount of friction for new users. Component authors should be able to use bower to release unstable pre-release versions of their components to advanced users to test without making the default install unstable.

[IgorMinar]

It should be noted that semver spec considers 1.2.0-rc.1 to be newer than 1.0.7, which is correct, but bower should not consider any pre-release versions when picking the default version to install (unless there is no stable version available)

[sindresorhus]

I agree. I assumed it worked like that.

[danheberden]

+1 - while technically correct, not what a typical end-user of bower would expect.

[satazor]

👍 I've put this for 1.2.0 milestone.

[addyosmani]

+1. Btw, if there's going to be a divergence from semver, is it worth informing the user that a 'technically' more recent version is available as part of the bower install log shown at the terminal?

[satazor]

I and @trask have been working on PR to solve this and #773! It's already done and with tests. PR will be submitted soon for review.

[wibblymat]

This exact problem was (is?) in npm, which meant that when grunt started
releasing 0.4 RCs new grunt users where getting screwed by compatibility
problems.

Definitely 👍 to fixing it.

On 15 August 2013 15:16, André Cruz [email protected] wrote:

I and @trask https://github.com/trask have been working on PR to solve
this and #773 #773 !

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/782#issuecomment-22701948
.

[btford]

if there's going to be a divergence from semver

I think it's worth noting that semver doesn't really have a good concept of "just give me a package with no constraints." That a version compares as greater than or less than another version doesn't imply that it is the best choice to resolve to in a vacuum. It might be worth seeing if this is something that can be standardized into the next version of semver.

[satazor]

The PR is this: #773

Note that the title has nothing to do with this issue, but it ended up fixing it since it is somewhat related and we decided to fix both issues in a single PR.

[satazor]

#773 was merged, fixing this issue!

[Raynos]

Cross reference from petkaantonov/bluebird#60 (comment)

bower should probably install the "normal version" that is the next lowest version of the "major.minor.patch" of the current pre-release version.

Instead of ignoring all pre-release versions.

If a bower module author has 1.0.7, 1.1-alpha and 1.2-alpha then that will break too, but that might be an acceptable compromise.

This is a reasonable compromise between semver compliance and ignoring the alphas of popular projects.

[IgorMinar]

@Raynos I think you want #1017 and not this old issue