-
Notifications
You must be signed in to change notification settings - Fork 14
Add staging rename design doc #2229
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
base: master
Are you sure you want to change the base?
Conversation
1. [`https://gui-staging.dandiarchive.org`](https://gui-staging.dandiarchive.org) → `https://sandbox.dandiarchive.org` | ||
2. [`https://api-staging.dandiarchive.org`](https://api-staging.dandiarchive.org) → [`https://api.sandbox.dandiarchive.org`](https://api.sandbox.dandiarchive.org) (using HTTP 308 to preserve the request method) | ||
|
||
The second redirection is probably less important for end users (excluding those that have written, e.g., Python scripts using the DANDI API against staging/sandbox for some reason), but it is necessary to avoid deprecating all previous versions of the DANDI CLI tool which still presumably references the old URLs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@yarikoptic, @jwodder, could you confirm the claim about deprecating earlier versions of dandi-cli?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@waxlamp I'm unclear what you're asking. Of course old versions of dandi-cli
point to api-staging. What else would they do?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I should have been clearer. I was assuming that you would not want to deprecate all previous versions of dandi-cli just to accommodate a change in the URLs, and that's what I was asking for confirmation on.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i would be ok with deprecating prior cli versions when this change happens.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My 1c would be -- to not bother. If someone runs into an issue, an obvious solution would be to upgrade. But as not everyone is using staging, and client would work perfectly fine with the main and other instances (and actually for downloads should work also with renamed one) -- we should be all good.
For the longer run eventually we should likely address
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(and actually for downloads should work also with renamed one)
It will not work for sandbox unless we redirect api-staging to api.sandbox, right? (That's what's at issue here, whether we need to put that redirection in place. But I think we should just do so.)
Co-authored-by: Kabilar Gunalan <[email protected]>
Co-authored-by: Kabilar Gunalan <[email protected]>
Should it be merged or there is more todo? |
Well, I want to resolve the uncertainty over deprecating old versions of the CLI. If you're good with this doc, go ahead and give me an approval 🙂 |
No description provided.