-
Notifications
You must be signed in to change notification settings - Fork 174
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
Add switcher to switch between various .md files for versions, languages, etc. #138
Comments
Hadn't thought about it, no. Any ideas? I'm open to suggestions, but also prefer ideas that keep Slate relatively simple and straightforward. |
Another possible solution is to place the version control information on the left hand side, enclosing the resources that get affected due to versioning. |
Ah, hmm, and perhaps the dropdown would link to other |
Have implemented the above prescribed solution in design, you can checkout this repo to start with. |
Thanks for the submission, I'll look into it when I get around to implementing this. |
I’m also interested in seeing this implemented. |
@ApoorvSaxena The repo link provided above links to just a forked repo without any changes (at least I couldn’t see anything different). Maybe they weren’t pushed? Thanks… |
@natebird I believe @ApoorvSaxena put the changed code in a different branch of that repo. |
I see that. Thanks! |
@lord when do you think this will be implemented? thanks. |
@s12chung I unfortunately can't give a definite time, but it's on my todo list. |
+1 for this feature; crucial for my projects. |
+1, it's a requirement for my current project |
Migrate feeds API doc to api.go.cd (#138)
I got around this via a deployment hack. Basically, when I tag a new release, I generate the site and move it into a "master" docs directory with a dirname matching the version. The You can see it in action here: (note there seem to be unrelated issues with focus and hover, with nav items getting selected incorrectly ... I'll poke around in the other bugs and see if anyone's reported this) Update: the issue with the nav items not being selected properly seem to be #280. |
+1 very interested; both API versioning and multiple languages would be very nice (and good practice for documentation). |
@lord Are there any plans for releasing this feature? If not, mayhaps there is an alive and healthy fork where this has been implemented? |
Yes! It is planned, but there is no current timeline. |
Bumped up pipeline_config API to V3 to support elastic_profile_id
Just wanted to +1 this feature as we need it as well. Thanks! |
We are interested as well. Our scenario: Complex API is pushing the perf and usability limits of one tall page. I'd like to split it into a few major sections. |
+1 as well, updating our API but would like to keep documentation for both V1 and V2 available on the same single-page app. I like the idea of the drop-down to toggle between versions. In the meantime, I've simply deployed a custom index.html landing page, and copied /source into two version-specific folders: /v1 and /v2. |
As another note for future reference when this is implemented — #679 suggests a hierarchy of pages might be nice, instead of a simple dropdown switcher. |
Any updates on this one? Would be great to have for multilingual documentations. |
Yeah i second this one, seems very interesting! If not only for API versions, it could also be used if you document different versions of software.. An example would be to be able to tag each API call you document with a version tag of the software it is supported on (one or more). Then let the user pick which version(s) he want's to see. |
Hello ! Hope you are having a good day ! Any news about this feature to be able to version API doc? |
Do you have any thoughts on how you could have multiple API versions? It would be kind of cool to somehow do it based on folder structure and how the shell/ruby/etc switching works maybe.
The text was updated successfully, but these errors were encountered: