The simple answer is that most of us have handled documentation in the same way as we handle the code. We don't patch tagged code once it is released, and we wouldn't patch the tagged version of documentation either. Most often, the website represents the HEAD, so we fix the HEAD, and upload the latest and greatest version.
Though, that's been an ongoing question: Should the website represent the HEAD or the latest GA release? The best answer is: Both. Each project (or Jakarta subproject) should a segment of its website intended for the "general public". This site would host the GA release of the documentation, warts and all, just like it were burned into a CD. (If you want to fix a serious documentation bug, cut a new release, just as you would with code.) Another segment of the site, intended for the development group, can host the latest and greatest version of the documentation. But, it should be separate and distinct from the GA/General public area. For example, at Struts, we link to the latest GA release of the documentation first * http://struts.apache.org/2.0.6/ But, we also host the HEAD version in the development area of the website * http://struts.apache.org/2.x/index.html On the site, we label the link the "Struts 2.x draft docs". The draft/head link stays the same, but each time we issue a new public release (GA or beta), we create an archive folder for that release's documentation. * http://struts.apache.org/downloads.html#PriorReleases Problems with the documentation aside, a common problem is that people try to use a feature that's part of a later release, so we keep the documentation for all the releases handy, so that people can refer to the correct feature set. - HTH, Ted <http://www.husted.com/ted/blog/> On 4/21/07, sebb <[EMAIL PROTECTED]> wrote:
How do projects use SVN to manage site documentation updates for exisiting releases? When a new release is created, the site documentation and source files etc will all be in an SVN tag directory. I assume that the SVN tags should never be updated once created, so if problems are subsequently found in the site documentation, and it needs to be updated, what is a recommended way to do this in SVN? S///
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
