3 Replies Latest reply on Dec 22, 2011 3:49 PM by marya.devoto

    DITA and conditional builds



      I have experience with DITA at my company and a while back I noticed that you seemed to have run up against a similar issue to one that we were having at Taleo where conditional builds produced many almost identical documents for minor application version changes. I remember reading the 4.5.3 documentation and seeing the 4.5.0, 4.5.1 and 4.5.2 documentation right beside it - and the worst bit was that searching would return 4 documents with the same title (and only a few people would bother to investigate that it was actually 4 documents - 1 for each different version).


      I see now in your documentation that this is no longer the case and I am very interested in how you approached the problem and seemingly fixed it.


      Something like this might best be discussed voice to voice if you are willing and available?





        • DITA and conditional builds

          Oh, I don't mind discussing it here. We actually just stopped maintaining completely separate docs for individual inline versions and started noting differences inline where they're relevant: giant, comprehensive diffs were performed to ferret out the differences. We don't actually do conditional builds currently, although we plan to start doing them for different audiences in the future.


          I hope that makes it clearer! Wish we had a solution to help you out.

            • Re: DITA and conditional builds

              Thanks for the reply Marya!


              So the 4.5.0, 4.5.1, 4.5.2 and 4.5.3 docs that I once saw all together in your online help maybe 6 months ago were not a result of conditional DITA builds?

              I guess then that they were 'snapshots' (or maybe subversion branches?) that were taken and then frozen in that state while work continued on the new version in the trunk.


              We are thinking of conditional building for audience AND version, but the single 'source' document starts to get a bit messy for authoring with all that stuff in there. On top of that we are moving away from major, and point releases, so it is hard to draw the line on when to stop noting differences 'inline' and when to start documenting difference in a whole new document :/


              I appreciate you taking the time to explain your situation.





                • Re: DITA and conditional builds

                  Yup, we used to branch them separately, but that was obviously problematic so we merged them.


                  It seems to make sense for us to branch for major releases but not inlines, but that might depend on how many new features, etc. go into an inline. For us, inline differences are modest. Many bug fixes, not many functionality differences of note.