As there becomes a history of releases, it becomes important to also retain the documentation that applied at that time.
That's especially applicable as APIs change in any way, new modules and modularizations are introduced, etc. For example, unless the JavaDoc reflects versions, it is likely to be current as of some build or trunk snapshot or whatever ... (maybe not even on exactly the same cycle as releases). I don't know of a perfect way to synchronize documentation, but it probably means that documentation is version-controlled to some degree, somehow. At Apache, that usually means in the SVN (even if the documentation itself is produced from some sort of authoring source by an SVN-downstream process). So it becomes a release artifact. I am thinking of technical documentation with details that can vary from release to release. Other kinds of documentation have their own release cycles and staging and might be kept outside of release cycles, including community-maintained materials on a wiki, etc. Side Note: The experience in the OpenOffice.org podling is that it is wise to get the IP right on wiki and downloadable contributions in case some of it is important to tie to releases and be cherry-picked into release artifacts. The ASF preference appears to be to use ALv2 for project-produced documentation and also do the usual IP/3rd-party magic on documentation from elsewhere. -----Original Message----- From: Paolo Castagna [mailto:[email protected]] Sent: Friday, November 11, 2011 05:17 To: [email protected] Subject: Re: How to decide to release (was: Re: JIRA issues and "Fix Version/s"...) Andy Seaborne wrote: > JENA-110 > Decide on doc/ (/me don't put in the downloads) +1 on removing doc/ entirely The official documentation is on the website. Paolo
smime.p7s
Description: S/MIME cryptographic signature
