tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ulrich Stärk <...@spielviel.de>
Subject [DISCUSS] new documentation organization and versioning
Date Tue, 01 Jun 2010 10:49:22 GMT
With the upcoming switch from maven-generated documentation to documentation kept in confluence
should discuss how we will organize the documentation in the future, especially with respect

Currently all work on Tapestry is done in trunk with some fixes being backported to the 5.1
including documentation. This means that we have several completely independent versions of
documentation that can be generated on request. If we want to keep it that way, we will have
somehow artificially version our documentation pages in confluence. E.g. with a parent page

"Documentation" and subpages for each Tapestry version like "Tapestry 5.1", "Tapestry 5.0"
"Tapestry dev" which themselves again contain independent pages for the different topics like

cookbook, user guide, tutorial, etc.

Another approach could be that we only have the most current documentation in confluence and

whenever a release is published, we export the documentation to html and store it somewhere

alongside the release. This would have the advantage that we don't have to manage several
of the documentation but it would also mean that we can't easily amend the documentation of
released version once work on the development version has progressed.

A third approach could be a mix of the two where we only have the documentation for the current

release and for the current development version in confluence.

A yet another, more radical approach could come hand in hand with a change of how we develop
release Tapestry. Instead of working towards a fixed set of functionality and release when
it's done 
(which might take some time) we could begin releasing at a fixed interval, say every two or
months. That way the current release version and the current development version wouldn't
apart that much concerning documentation and possibly long-awaited new features. That way
it might 
be enough to just have one version of the documentation and mark features not yet in the release

version as such.

There are possibly many other possibilities that I didn't think of and I'd like to discuss
What do you think? Have you any other suggestions how to solve this versioning problem?



To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org

View raw message