Keep different versions of documentations

[vinz243]

HI, It would be great if we could keep differents versions (either only majors or minors) of documentations in the same folder, and developers would be able to select the version they are using

Thanks

[aciccarello]

@vinz243 This would be a great feature! How would you expect TypeDoc to know what versions to show/generate?

[vinz243]

I guess it could use tags to detect which version to generate docs for. However this would also means that the version would first need to be tagged, so this would not work except if the docs are on another branch (like gh-pages). Another solution would be like, tagging the newly generated docs as 'current', and the previously generated one using tags. There could be a CLI option too like --targetVersion 4.2.0 to select a version (then current and 4.2.0 would have same docs)

[balupton]

We have https://github.com/bevry/awesome-travis/blob/master/scripts/surge.bash which deploys the repo for each commit, branch, and tag.

For instance, for https://github.com/bevry/editions you can see the docs for master at http://master.editions.bevry.surge.sh/docs/ or the docs for v1.3.4 at http://v1.3.4.editions.bevry.surge.sh/docs/ or even a specific commit at http://fadc5cbb4b99f727f95a32bd4fe813198917d003.editions.bevry.surge.sh/docs/

As it deploys the whole compiled repo, you can even grab specific files for a specific version like so: http://v2.1.0.editions.bevry.surge.sh/edition-browsers/index.js

I made a scaffolding tool to do all the setup automatically at https://github.com/bevry/boundation - which today I added typescript and typedoc support.

[Gerrit0]

Benjamin's solution is the best one here, while TypeDoc could theoretically support merging docs for different versions, it is a large amount of complexity for a fairly small benefit. Keeping separate versions yourself also provides the flexibility to decide when documentation should be updated.

[thislooksfun]

I just (mostly) solved this issue in my own workflow as documented here, complete with automatic symlinks to the latest versions. You can view it in action here. It's semi-specific to my use-case right now, but I could easily abstract it out to its own action if people would be interested.