On Wed, Apr 13, 2011 at 8:20 PM, Marvin Humphrey <[email protected]> wrote: > http://lucy.apache.org/docs/ <-- homepage > http://lucy.apache.org/docs/perl/ <-- TOC for latest Perl bindings > http://lucy.apache.org/docs/ruby/ <-- TOC for latest Ruby bindings > ...
OK. See below. > At some future date, we should begin archiving the docs for each release: > > http://lucy.apache.org/docs/X.Y.Z/ > http://lucy.apache.org/docs/X.Y.Z/perl/ > http://lucy.apache.org/docs/X.Y.Z/ruby/ > ... Versioning approach sounds solid to me. > We should hold off on archiving for now, though, so that the primary location > has a chance to establish itself as authoritative. > > To find the documentation for Indexer's Perl bindings in the latest > API-unstable Lucy release, you would look here: > > http://lucy.apache.org/lucy/docs/perl/Lucy/Index/Indexer.html > > Here's where you'd find the analogous page for archived release Lucy X.Y.Z: > > http://lucy.apache.org/lucy/docs/X.Y.Z/perl/Lucy/Index/Indexer.html Was it intentional that these are "/lucy/docs" and the paths above are "/docs"? While it's redundant to have 'lucy' repeated in the domain and path, it might make life easier. For example, when one migrates from incubator.apache.org to lucy.apache.org, all absolute path links will still work. And if one ever migrates again, it should just be a drop in. One could mostly solve this by sticking with directory relative URL's, but with the multiple versions one will probably want some absolutes. So I'm fine with either, but would lean to leaving 'lucy' in the path. It also keeps things clear if/when subprojects are added. But it doesn't seem worth too much worry. Rest seems good. --nate
