Sometimes ppl are forced to use a specific subversion - it makes a lot of sense if the documentation for that version is still available to them (+ i dont see what we lose by keeping older documentation available)
On Tue, Jun 1, 2010 at 22:13, Dmitry Gusev <[email protected]> wrote: >> I don't think having separate documentation for T5.0, T5.1 and other T5.x >> is not a good idea. >> > > Sorry, actually what I was trying to say is _I don't think its a good > idea_... its definitely bad :) > > On Tue, Jun 1, 2010 at 23:11, Dmitry Gusev <[email protected]> wrote: > >> I don't think having separate documentation for T5.0, T5.1 and other T5.x >> is not a good idea. >> I think it is reasonable to have separate documentation for versions having >> different major number (T3, T4, T5 etc.) but not for version that differ in >> minor version numbers. >> Why one would use earlier version of T5.0 instead of T5.1 if T5.1 is >> already released? Its okay if one will see feature that is still in >> development (say in trunk) while reading documentation of stable release. >> This will give him a reason to upgrade after release if he really wants this >> feature, or plan its work according to direction of ongoing tapestry >> development. >> So my point is keep all minor version updates together and only make new >> separate version of documentation when T6 release will be planned. >> >> >> On Tue, Jun 1, 2010 at 14:49, Ulrich Stärk <[email protected]> wrote: >> >>> With the upcoming switch from maven-generated documentation to >>> documentation kept in confluence we should discuss how we will organize the >>> documentation in the future, especially with respect to versioning. >>> >>> Currently all work on Tapestry is done in trunk with some fixes being >>> backported to the 5.1 tag, including documentation. This means that we have >>> several completely independent versions of the documentation that can be >>> generated on request. If we want to keep it that way, we will have to >>> 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" and "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 versions of >>> the documentation but it would also mean that we can't easily amend the >>> documentation of the 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 and 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 three months. >>> That way the current release version and the current development version >>> wouldn't drift 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 these. What do you think? Have you any other suggestions how >>> to solve this versioning problem? >>> >>> Cheers, >>> >>> Uli >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> >> -- >> Dmitry Gusev >> >> AnjLab Team >> http://anjlab.com >> > > > > -- > Dmitry Gusev > > AnjLab Team > http://anjlab.com > -- Andreas Andreou - [email protected] - http://blog.andyhot.gr Tapestry PMC / Tacos developer Open Source / JEE Consulting --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
