Remember that this discussion should center around documentation.
On 01.06.2010 13:58, Christian Edward Gruber wrote:
+1 to a fixed release cycle. Time boxes are, in my experience, superior
to feature-boxes in terms of resulting delivery, quality, etc.
Christian.
On Jun 1, 2010, at 7:32 AM, Ulrich Stärk wrote:
Don't get too excited about it yet. These are just vague ideas...
On 01.06.2010 13:12, Inge Solvoll wrote:
Loving the 2-3 months release cycle idea :)
I suppose it would mean some major changes in how you guys do your
work, but
it would be a huge win to see more of those minor enhancements more
often.
Right now I'm very ready for a 5.2 release, as our team don't want
non-release dependencies. I don't care about major new features, I
just want
the "pageInit" event :)
On Tue, Jun 1, 2010 at 12:49 PM, 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
