Shields: Packagist badge does not handle lowercase "rc", only uppercase

[kocsismate]

Hi,

I am a happy user of shields.io but I unfortunately noticed a rather annoying bug (?) in the recent days:

Although I released v2.0 of my lib many days ago (here is its read me: https://github.com/woohoolabs/yin/blob/master/README.md), the Packagist final version badge still shows v2.0.0-rc1 (https://img.shields.io/packagist/v/woohoolabs/yin.svg).

Could you tell me why it happens? Is it a bug or I messed up something?

[paulmelnikow]

Hi, thanks for reporting this.

Shields has some pretty elaborate logic for sorting the Packagist versions. See https://github.com/badges/shields/issues/319#issuecomment-74417866 when it was discussed.

It looks like our code recognizes RC1 but not rc1. Should it?

[kocsismate]

Thank you for insights! I would be happy if the check could be made case-insensitive:

var firstLetter = modifier.toLowerCase().charCodeAt(0);
// ...
} else if (firstLetter === 114) { // r
// ...

Hopefully, this change would make the decision more foolproof.

[paulmelnikow]

I just checked the spec and it looks like the RC is supposed to be capitalized. Shields could interpret it leniently, though if we do, we would introduce skew. The composer command line would interpret the values one way, Packagist another, Shields still another, making it more difficult for these tools to interoperate.

Here's a good example of the principle. Most JSON parsers are strict. They croak on inputs which don't meet the spec. Even when the error is completely unambiguous, like a dangling comma, they bail. Counterintuitively, this is a reason JSON has been successful. Because every parser interprets the spec strictly, they can all interoperate with each other.

After laying out the JSON spec in five short paragraphs, Douglas Crockford wrote (emphasis mine):

That's it. That is all of JSON. JSON's design goals were to be minimal, portable, textual, and a subset of JavaScript. _The less we need to agree on in order to interoperate, the more easily we can interoperate._

Certainly reasonable people could disagree. It may be inconvenient for your package which is already published.

[kocsismate]

OK, I completely understand your opinion. However, I think Postel's Law can also be a good guideline:

Be conservative in what you send, be liberal in what you accept.

Anyway, I can just release v2.0.1 to solve my problem. :P I am closing the issue! Thank you for your great service!

[andrerom]

Think this should be re-opened.

I just checked the spec

It's not really the _spec_ on versions, the one composer follows _(but extends actually, with among others a 4th micro version number and probably more)_ is: http://semver.org/

And there you'll see rc, my guess is it's just uppercase in Composer documentation since it is a abbreviation for Release Candidate, and might be a preference of author, but I don't think it's meant to be taken literally.

[kocsismate]

@andrerom Yeah, you are right.

Since closing the issue I thought a little bit about what @paulmelnikow had said about strict vs lenient interpretation and came to the conclusion that if you really interpreted the versions strictly, you would display an error if the format isn't acceptable.

So in my opinion it makes sense to either display an error or interpret versions case-insensitively.

[paulmelnikow]

if you really interpreted the versions strictly, you would display an error if the format isn't acceptable.

AFAICT Packagist assigns special meaning to packages with RC and not with rc. Why would we do any different?

Since the problem in in the revision numbers of uploaded packages, it's Packagist that would need to issue a better error message, not Shields.

[andrerom]

I think it might be normalizing version numbers first, that's what composer does and as packagist depends on composer I would assume it reuses logic like this.

[paulmelnikow]

I'm marking all the needs-upstream-help issues closed.

If there's new information from the upstream service, please post in the thread. If they're actionable by Shields, a maintainer will reopen the issue.

If anyone wants to follow up with these vendors, feel free to do that! Even though the unresolved issues are closed, they are easy to find:

https://github.com/badges/shields/issues?q=label%3Aneeds-upstream-help+is%3Aclosed

[paulmelnikow]

Upstream issue: composer/packagist#921