On 12-12-27 06:06 AM, Mick Semb Wever wrote: > > In some cases documentation must wait until a release is made, ie that > documentation depends on new features yet to be released. Here > everything just falls into the release process. > > In other cases, like "wildcards documentation", documentation > enhancements come in that can be pushed immediately to staging. my > question what is best practice here?
If this is indeed the need, then I would gather all the documentation into a single maven project and separate it from the code itself. Then we can use "wildcard" version numbers to track the documentation (3.0.x, 3.1.x...) and update it in a different timeframe from the code releases. Or we can see how to setup the apache CMS for the doc. > The way i see it must be done seems rather clumsy… > 1) checkout ^/framework/tags/tiles-parent-3.0.1/ > 2) svn merge -rXXX > ^/framework/trunk/src/site/apt/tutorial/advancedwildcard.apt > 3) mvn site:site > 4) cp target/site/tutorial/advanced/wildcard.html > ../site/staging/framework/tutorial/advanced/wildcard.html > 4a) hack the snapshot header back to the release version > 5) svn ci ../site/staging/framework/tutorial/advanced/wildcard.html > 6) cast vote This is basically the same process as the release of a project.
