Comment #1 by dlang-bugzilla — 2017-06-26T13:59:57Z
*** Issue 15810 has been marked as a duplicate of this issue. ***
Comment #2 by greensunny12 — 2017-07-03T10:08:05Z
I gave this a try a few weeks ago [1, 2], but mainly aborted it because I ran out of time as building dlang.org, especially for previous versions, is a huge PITA.
However, a couple of insights:
- the dlang.org dump is nearly identical between versions (git is amazingly powerful here, the git repo has 190M vs. 2.6G of extracted archives)
- I used netlify with their free auto-deploy (it's pretty sweet, they auto-deploy a public git repo on their CDN for free)
- We probably need some kind of version header (maybe a simple `sed` of <body> can is good enough?)
- As mentioned, there were some troubles with building previous version (so not all currently "archived" versions are correct yet)
I can have a look at this in the next weeks/months, but maybe @Vladimir already has a pipeline to build old dlang.org versions?
[1] https://github.com/wilzbach/dlang.org-archives
[2] https://docarchives.dlang.io/v2.074.0/phobos/std_base64.html
Comment #3 by dlang-bugzilla — 2017-07-03T15:16:14Z
Thanks for working on this! I hadn't looked into this yet, just had some ideas.
Building the entire website is almost surely going to be a PITA. The biggest drawback is likely going to be that when the website's design is updated, the old version pages are going to keep the old design, possibly including old navigation with lots of dead links etc.
Probably the best solution is some compatibility shim (read: big pile of very ugly hacks) that allows old versions' content to be built with the current website design.
Building old site versions verbatim, despite the flaws, is almost surely going to be much easier. I think Digger is the best tool for the job for this approach, as it already knows how to build old versions of everything else.
One last thought is that we bundle HTML documentation with DMD releases themselves. These are fairly independent of the website and could be used directly. I hadn't looked into this yet.
Comment #4 by jack — 2017-07-03T15:46:50Z
Or, we can just provide links to the archive.org version of the docs for each version.
Not pretty by any stretch, but it's something that already works.
Comment #5 by andrei — 2017-07-03T17:02:23Z
([email protected] are you Seb?)
Could you please give a bit of insight in why that's difficult? My ignorant take on this is: create a sandbox with all of dmd, druntime, phobos, tools, and dlang.org at the same point in time and then build the documentation. If building documentation succeeded then, it should succeed now. Please disabuse me of that notion :o).
An out-of-the-box possibility I've been looking into is to simply offer links to versions already archived by archive.org. For example the first version of
--- at this point I saw Jack posted the same idea! ---
Comment #6 by greensunny12 — 2017-07-04T01:53:49Z
See NG:
http://forum.dlang.org/post/[email protected]
> Could you please give a bit of insight in why that's difficult? My ignorant take on this is: create a sandbox with all of dmd, druntime, phobos, tools, and dlang.org at the same point in time and then build the documentation. If building documentation succeeded then, it should succeed now. Please disabuse me of that notion :o).
Yeah I had this ignorant view in the beginning as well ... and then I tried it :P
It's an immense PITA because
- the Makefile change so often -> they randomly break
- older versions of the compiler need patching to be able to compile
- older versions of the docs need a very specific compiler
- one needs to overwrite a lot of Makefile variables
- Ddox is extremely annoying because
- older packages use incompatible headers to OpenSSL, libevent
- older DUB releases (<1.0.0) weren't really "stable"
...
Anyhow I think I finally managed to create the snapshots and dump them on a CDN:
http://forum.dlang.org/post/[email protected]
Especially the docs.json files are interesting, because - if properly merged - we could generate a symbol history out of them.
> ([email protected] are you Seb?)
Yep, sorry, for some reasons I happen to have two Bugzilla accounts.
Comment #7 by github-bugzilla — 2017-07-07T18:50:31Z