Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Any chance of adding Cryptico? #2090

Closed
modusinternet opened this issue Nov 2, 2013 · 8 comments
Closed

Any chance of adding Cryptico? #2090

modusinternet opened this issue Nov 2, 2013 · 8 comments

Comments

@modusinternet
Copy link

Will you guys be adding or could you please add Cryptico to your CDN?
http://wwwtyro.github.io/cryptico/

@andey
Copy link
Contributor

andey commented Nov 11, 2013

make a pull request?

@ryankirkman
Copy link
Member

Yeah, a pull request would be great

On Mon, Nov 11, 2013 at 7:38 AM, Andrew Wei notifications@github.comwrote:

make a pull request?


Reply to this email directly or view it on GitHubhttps://github.com//issues/2090#issuecomment-28209679
.

@petecooper
Copy link
Contributor

This raises an interesting point - the current incarnation of Cryptico doesn't have a version number as such. How might this be resolved? It's the first time I've encountered it, so may be an edge case, but I'm curious to know.

@ryankirkman
Copy link
Member

We could use a datestamp and commit hash to ensure we have a human readable
sorting order along with a tie-breaker (commit hash) in the case of
multiple releases in a day.

Or, we could go even simpler and use the datestamp, and for multiple
releases in a day do something like an auto-incrementing number appended
e.g. 20140128-1, 20140128-2, 20140128-3.

See json2 for an example of where we do this already:
https://github.com/cdnjs/cdnjs/tree/master/ajax/libs/json2

Using a datestamp does have interesting and complicated resolutions when
multiple timezones are involved.

On Tue, Jan 28, 2014 at 4:31 AM, Pete Cooper notifications@github.comwrote:

This raises an interesting point - the current incarnation of Cryptico
doesn't have a version number as such. How might this be resolved? It's the
first time I've encountered it, so may be an edge case, but I'm curious to
know.

Reply to this email directly or view it on GitHubhttps://github.com//issues/2090#issuecomment-33474094
.

@petecooper
Copy link
Contributor

Would using Unix (epoch) time get around the timezone issue?

I also found an instance today where a release was simply tagged as '0' where there was no clear version number. I'll see if I can find that for reference.

Edit: found it - https://github.com/cdnjs/cdnjs/tree/master/ajax/libs/960gs/0

@ryankirkman
Copy link
Member

I think you're talking about 960gs with the 0 version tag:
https://github.com/cdnjs/cdnjs/tree/master/ajax/libs/960gs

I love the idea of using the UNIX timestamp. Let's use the unix timestamp
in seconds to avoid a few unnecessary digits.

On Tue, Jan 28, 2014 at 5:03 PM, Pete Cooper notifications@github.comwrote:

Would using Unix (epoch) time get around the timezone issue?

I also found an instance today where a release was simply tagged as '0'
where there was no clear version number. I'll see if I can find that for
reference.

Reply to this email directly or view it on GitHubhttps://github.com//issues/2090#issuecomment-33546495
.

@petecooper
Copy link
Contributor

I'll take a look at this - likely Feb 5th or 6th, if time allows.

@petecooper petecooper self-assigned this Feb 4, 2014
petecooper pushed a commit that referenced this issue Feb 5, 2014
Source: https://github.com/wwwtyro/cryptico/archive/master.zip

Background: #2090

Converted file timestamp to Unix epoch, then prepended with 0.0.* to
fit semver numbering. There is a possibility that this software will be
released with 0.0.1 version at some stage, which will throw this
numbering scheme out of whack.
petecooper pushed a commit that referenced this issue Feb 5, 2014
Background: #2090

Contains deletions to fix Travis build, no risk as initial commit
failed.
@petecooper
Copy link
Contributor

Done. @modusinternet: please advise if there are any issues with this implementation. @ryankirkman: please advise if the epoch + semver directory naming needs changing.

petecooper pushed a commit that referenced this issue Mar 28, 2014
Converted GitHub commit (here:
node-js-libs/load.js@f8b9e2e
2e7b6dd53) timestamp of 2011-09-19 13:13:27 to epoch time 1316434407 -
no indication that this is a 1.0.0 release, and epoch numbering should
be used in this case (see #2090
for info).
@petecooper petecooper removed their assignment Jun 26, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants