On Fri, May 24, 2013 at 8:37 AM, Rob Godfrey >> Sort of. In general, for release content, there's a special >> generation step. That's really a per-release task, however, not >> something that many developers would typically do. The idea is that >> the release manager would do the generation with each new release. >> I've spent a good deal of time to make this easy (much easier than >> it's been in the past), probably because it's one of the jobs I've had >> to do with each release. >> >> Also, I guess I should say that the two steps are easily collapsed: >> "make gen-release RELEASE=0.22 render". >> >> Trunk documentation would, as you suggest, best be solved by automated >> builds. >> >> > So I'm at a bit of a loss as to why a two step document generation process > would be a good idea. Is there something that is now being done that > cannot be done using the docbook -> html XSL transforms? I'm not the > greatest fan of docbook, but adding in a secondary transform on top of an > existing transform seems a little odd. If docbook cannot give us the > output we need, why are we still using docbook?
Agreed about docbook; I'm not a fan, and I'd love to move away from it. It's more like an import step. The docbook content is (sensibly) maintained under the main qpid source tree. The web content is (sensibly) maintained under the website source. On the website, we fuse the two together for the release docs, mating the website template (with its navigation) to the body html from docbook. Indeed, I favor removing the site template stuff from the docbook scripts under the qpid source tree. I currently scrub it out. There's another less important reason. Docbook generates lousy html, so I sanitize it (to xhtml) to make things like link checking work nicely. Justin --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
