On Sun, Mar 23, 2003 at 09:48:47AM -0500, Diana Shannon wrote: > How should we transition? How about: > > 1. Set up live protoype Forrest environment (now happening) > - work out remaining configuration issues > > 2. Set up separate Cocoon docs repo(s) > - decide what the repo will include (simply docs and/or tools)
Do you mean, commit a Forrest binary into cocoon-docs CVS? Why not just make a snaphot available for download, or let people run 'cvs update -r stable' on Forrest to get a known-working version? > - copy both 2.1 and 2.0 docs and associated files into separate > modules/branches/repos. Maintain "old" doc build capability, as > currently functioning, in 2.1 and 2.0. Sounds like a lot of work.. why go to all that effort to keep the old system alive, if the Forrest system is 95% working? Also, having XML in a separate cocoon-docs module is likely to trigger the "out of sight, out of mind" syndrome. Right now, when I change some code (say, rename DefaultsMetaModule to DefaultsModule), I can simply grep cocoon-2.1 and find all references to the old class in code *and* docs, and update them. With a separate module I'd probably forget, or forget to 'cvs up' it. > - setup docs build capability for user docs and web site > - add static documentation (built by cocoon-docs repo with Forrest) > to both 2.0 and 2.1 repos ?! Do you mean, commit 10mb of generated HTML/PDF to cocoon-2.1? I hope not :) --Jeff (in wet blanket mode, and not seeing the forest for the trees:) > - setup mechanism to update (via automated cvs update?) static docs > in 2.0 and 2.1 repos. This removes the "burden" of doc-building from > code repos. Webapp samples can simply link to static doc files (copied > over during webapp build). > > 3. Remove xdoc, stylesheets, and dtds related to core documentation from > 2.0 and 2.1 repos. > > 4. Consider merging 2.0 and 2.1 into a single trunk (based on Andrew's > findings/protype) > > Thoughts? > > Diana >
