Marshall Schor wrote:
Michael Baessler wrote:
Robert Burrell Donkin wrote:
subversion really is the way to go for release documentation
OK, so as far as I understand we go with the documentation the same
way as with the previous Apache UIMA releases. We check in the
Michael Baessler wrote:
Robert Burrell Donkin wrote:
subversion really is the way to go for release documentation
OK, so as far as I understand we go with the documentation the same
way as with the previous Apache UIMA releases. We check in the
documentation
to SVN and provide a download
Marshall Schor wrote:
Michael Baessler wrote:
Robert Burrell Donkin wrote:
subversion really is the way to go for release documentation
OK, so as far as I understand we go with the documentation the same
way as with the previous Apache UIMA releases. We check in the
Marshall Schor wrote:
Michael Baessler wrote:
Robert Burrell Donkin wrote:
subversion really is the way to go for release documentation
OK, so as far as I understand we go with the documentation the same
way as with the previous Apache UIMA releases. We check in the
Michael Baessler wrote:
Marshall Schor wrote:
Michael Baessler wrote:
Robert Burrell Donkin wrote:
subversion really is the way to go for release documentation
OK, so as far as I understand we go with the documentation the same
way as with the previous Apache UIMA releases.
On Jan 2, 2008 4:05 PM, Marshall Schor [EMAIL PROTECTED] wrote:
snip
Since we want our docs pages to refer not only to the current release
but also previous releases, it would be good to figure out a fairly
automatic system for this. (That was a virtue of the /dist/ - archive
system - we
Robert Burrell Donkin wrote:
subversion really is the way to go for release documentation
OK, so as far as I understand we go with the documentation the same way
as with the previous Apache UIMA releases. We check in the documentation
to SVN and provide a download similar to release
On Dec 31, 2007 3:43 AM, Marshall Schor [EMAIL PROTECTED] wrote:
Robert Burrell Donkin wrote:
(apologies for not jumping in promptly)
On Dec 24, 2007 3:48 AM, Marshall Schor [EMAIL PROTECTED] wrote:
I updated our website download page and documentation page. I made the
download page
(apologies for not jumping in promptly)
On Dec 24, 2007 3:48 AM, Marshall Schor [EMAIL PROTECTED] wrote:
I updated our website download page and documentation page. I made the
download page work with mirrors, and changed the format for accessing
previous archived files to follow the common
Robert Burrell Donkin wrote:
(apologies for not jumping in promptly)
On Dec 24, 2007 3:48 AM, Marshall Schor [EMAIL PROTECTED] wrote:
I updated our website download page and documentation page. I made the
download page work with mirrors, and changed the format for accessing
previous
I updated our website download page and documentation page. I made the
download page work with mirrors, and changed the format for accessing
previous archived files to follow the common practice on other sites,
referring to the archive.apache.org site.
I made our documentation page refer to
Fine with me to delete the HTML documentations (manual and javadoc) on
the mirror. I thought we can use it and link them from our website.
As far as I know, there is no script to upload the documentation. I did
it manually.
-- Michael
Marshall Schor wrote:
Here are some examples of large
Here's an argument for keeping the big things we point to from our
website, like the javaDocs and the 4 books in html form, on the
a.o/dist/incubator/uima site:
It is automatically archived. And, when it's deleted from the
mirror, a redirect is put in to the archive spot.
This would be
One further thought: A lot of projects put the RELEASE NOTES for
particular releases at the top level of the dist/ - where the file
name includes the release: for example:
ANT: RELEASE-NOTES-1.7.0.html
HTTPD: CHANGES_2.2.6
Since these will get archived, and redirects can be done for
Here are some examples of large files (or large collections of files
The api java docs;
The api java docs as a zip file
The 4 books in html format
It seems good to put them in people.a.o/www/incubator.a.o/uima/downloads.
It seems bad to put them in SVN (because there's no need for
versioning
One more consideration:
Some people use a URL to javadocs as part of their javadoc build
process. For that, we might want to consider if we want to support
people doing that - and if so, we probably need to keep the javadocs for
each version, forever.
The dist system supports this, via
16 matches
Mail list logo
