Shorten version number

[fregante]

Closes #595

From 17.8.20.834
to   17.8.20

Travis has been behaving well and deployments happening in the middle of UTC day, so same-day deployments are far from possible — even if that does happen we only lose a day anyway.

[sindresorhus]

Wouldn't this prevent us from doing manual urgent bug fix releases? (If it already had done an automatic release the same day)

[fregante]

It would. If needed the code in #595 would solve that issue. But then I thought... when would it ever be necessary to ship Refined GitHub now instead of within 24 hours?

[sindresorhus]

If some changes on GitHub caused Refined GitHub to totally break, we would want to ship a fix right away. Could easily happen as we're playing on someone else's lawn.

[fregante]

Understandable, but #675 totally broke the extension and it's gone unfixed for 20 hours. 😜

[sindresorhus]

@bfred-it I did not know about that: #675 (comment)

Can you message me on Twitter if you notice before me next time? And I'll fix it right away.

[fregante]

Ok, this now addresses your concern and closes #595 :)

[sindresorhus]

Shouldn't 17.8.29.1451 follow semver and be 17.8.29+1451? (Build metadata)

[fregante]

Chrome doesn't follow semver, it only allows integers: https://developer.chrome.com/extensions/manifest/version

[fregante]

It looks like I hit a roadblock though. I have to store the cache somewhere else because travis only retrieves at before_build and stores after_build, which happens before the deployment script saves the version.

Do you know of a free REST service that allows to store small data?

In daily-version I'd replace

cat ~/.npm-daily-version/v            # get
echo "$CURR" > ~/.npm-daily-version/v # set

with

curl example.com/d2daaab2b2a6eprivatedaaab2b2a6e
curl example.com/d2daaab2b2a6eprivatedaaab2b2a6e -X POST -d $CURR

Like http://myjson.com/api but not JSON or like http://www.kvstore.io/ but without login. 😅

[sindresorhus]

Isn't that overkill just to get a slightly shorter version number that probably no one will even see?

[fregante]

Except everyone sees it twice on the homepage 😛

[sindresorhus]

So let us just drop those badges. I don't see the point of them, to be honest. Alternatively, we could move them into a maintaining.md file just for us. Example: https://github.com/avajs/ava/blob/master/maintaining.md What do you think?

[jdreesen]

I find them useful to check what's the latest release (I think it appears on the chrome store almost instantly?) and if has already been approved on AMO. Thus, when something doesn't work (but AMO lags behind once again) I can check if the bug has already been fixed (and just didn't reach me yet) before I'm creating an issue.

[sindresorhus]

You could also check this in a maintaining.md file. It's not essential for most users.

[jdreesen]

Sure, I could, no problem. Just please don't remove them entirely :)

[fregante]

I'd rather have them there, it's always one-click away to check if both versions have been published and they don't bother me that much 😁

[sindresorhus]