#468 encourage stable version

[elliotekj]

The changes in this PR update a crate’s index page to show the latest stable release, which is defined as the last version uploaded that doesn’t include the strings “alpha” or “beta” as per #468.

I updated the fixtures to suit my needs whilst sorting this issue. Some tests fail with said updates though so I undid them. If someone with a better idea of how the fixtures should be configured (I just copy/pasted a previous version and incremented everything) wants to update them to set an alpha version as the latest that’d be appreciated (if we do indeed want to update the fixtures with this PR).

As things stand at the time of writing, these changes can be tested locally with yarn run start:live and the following URLs:

• http://localhost:4200/crates/libc - libc's latest version is stable and that is the one shown on the crate's index.
• http://localhost:4200/crates/pom - pom currently has a 2.0.0-alpha version as it’s latest but 1.0.0 will be shown on the crate’s index.
• http://localhost:4200/crates/pom/2.0.0-alpha - Specifically navigating to a version that has an unstable flag will show the install information for that version even though it's unstable.
• http://localhost:4200/crates/shoop - All of the currently available versions of shoop contain an unstable flag so the maxVersion is shown.

Screenshot:

[ghost]

Good PR.

[elliotekj]

Any thoughts on adding realease candidates marked rc the list of unstable flags? I think that addition would just about round off the commonly used version flags I've seen around. prealphas get weeded out by the alpha flag check.

[carols10cents]

Any thoughts on adding realease candidates marked rc the list of unstable flags? I think that addition would just about round off the commonly used version flags I've seen around. prealphas get weeded out by the alpha flag check.

I think rc should be added, yeah. But "prealpha" getting weeded out by the "alpha" flag check makes me nervous about adding "rc"-- since we're not matching on the entire label, what if someone made a label that said "arc" or "anarchy" or some other word that contained "rc"? The version would be hidden, but I don't think that's what would be expected... I think this feature would be more understandable if we either have a fixed list of exact, fully matched words that will get a version to be not recommended on the crate's page, or if we say that any string after the version number will cause it to not be recommended, unless there aren't any versions without a string.

Steve's comment here says "Especially given that you don't get a pre-release version without specifically selecting it; this seems quite consistent." I'm going to go check out cargo's code and see if it matches on particular strings or if it's any string, the behavior here should match whatever behavior is in the version resolver code.

Do you remember what the problems were when you tried to update the fixtures? I can take a look at that too.

[carols10cents]

Ok yeah i think this is defined in the semver spec's precedence rules, which the semver crate (and thus cargo) follow:

When major, minor, and patch are equal, a pre-release version has lower precedence than a normal version. Example: 1.0.0-alpha < 1.0.0.

A version is considered a prerelease version if there is any value in the prerelease spot, not any particular values like "alpha" or "rc", etc.

So I think we should hide any version that has any value for prerelease, unless all versions of the crate have values for prerelease.

[elliotekj]

A version is considered a prerelease version if there is any value in the prerelease spot, not any particular values like "alpha" or "rc", etc.

So I think we should hide any version that has any value for prerelease, unless all versions of the crate have values for prerelease.

Thanks for digging into this. Crates should definitely match Cargo's implementation! I'll get this PR updated as time permits — probably towards the start of next week.

Do you remember what the problems were when you tried to update the fixtures? I can take a look at that too.

These were the changes I made. I don't remember what the errors were exactly, but I got them when running Ember's test suite.

[carols10cents]

Take your time! I'll try out the fixtures, although ember and i have done our fair share of disagreeing on what is and should be happening in the tests :P

[carols10cents]

Oh i see! The test that fails for me when I use your fixture changes says Text found ('All 13 versions of nanomsg since December 7, 2014') did not match regex ('/All 12 versions of nanomsg since December \d+, 2014/'), which makes sense since your fixture adds another version! So I think changing this test to expect 13 instead of 12 makes the ember tests pass with your fixture changes. I won this time, ember!!!!

So when you get a chance to make the change that any prerelease string should count as a non-stable version, could you rebase to remove the commit where you took the fixture changes back out, then update the test message as well? Thank you!! ❤️

[elliotekj]

@carols10cents I undid the commit that reverted my fixture changes and updated the test to expect 13 instead of 12 as you suggested above — everything's passing now 👍

isUnstableVersion has been updated to consider any version that has text after major.minor.patch as unstable and the conflict caused by f44f544 has been resolved. The links in my first comment can still be used for reviewing this PR.

[carols10cents]

Works great!! Thank you!!