incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject Versioned/Historical Documentation (was RE: How to decide to release ...)
Date Fri, 11 Nov 2011 14:17:31 GMT
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 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 []
Sent: Friday, November 11, 2011 05:17
Subject: Re: How to decide to release (was: Re: JIRA issues and "Fix 

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.


View raw message