-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Transition plan #101
Comments
Since the move is designed to put the |
@espadrine Clarified my questions above. |
Here's where we decided previously to use |
I think we do want to transition users of other services. This is underway for http://badgr.co/ (#63), though honestly the number of users depending on any of these services is so small in comparison to the number of users we hope to have that we shouldn't stress about it too much, I think. If we leave them running for a month or two after launch I think that'd be plenty. |
People are currently relying on the How long would we wait until we use |
@espadrine Some number of people are currently using img.shields.io already as well. The b.adge.me API doesn't match the existing img.shields.io API, so if we simply CNAME img.shields.io to b.adge.me we'll break the service for those already using it. I suppose that leads back to the web API discussion (#100). |
So Or we could support other API formats under |
Can you specify what the differences are between the current Note for instance that |
Picking up with web API discussion at #100 (comment) ... |
We're using img.shields.io. |
Will we use
img.shields.io
or a different subdomain? If we do, how many people are using it and how we handle API compatibility?Do we want to transition users of other services such as http://b.adge.me/ and http://b.repl.ca to the new service, and if so, how do we go about this (assuming the API #100 may change)?
The text was updated successfully, but these errors were encountered: