Emmanuel Blot wrote:
Hi,
Another question ;-)
What about the documentation of features vs. their availability in a
specific release ?
There are two approaches:
* release specific manuals (e.g. TracGuide0.8/... err, I mean
TracGuideZeroEight/...)
* ''consolidated'' TracGuide, the feature being annotated with
''require ...'' and maybe
''deprecated in ...'', ''removed in ...''
So far we don't have a doc for each version, so it seems that we would
like to keep a consolidated doc. This is better IMO as it gives our
contributors a better focus than having to maintain several
documentation "branches".
Not everybody has or is interested to move to 0.9, and when 0.10 will be
released, there will be even more people still running 0.9 ...
And so on.
First point: there are several pages that still specify "(require
0.9)". As I understand that 0.8 branch is no longer supported, I guess
it is ok to clean up these release reminders. Am I right ? Can I
remove them when I encounter some ?
So, I'd say no here, for the reasons explained above.
Second point: what about the feature of the upcoming release. In order
that users can test the newly delivered features (to the trunk), I
think we need to document these features in the official web pages.
How to do this ? Should we specify "require 0.10" even it does not
exist yet ? What is the policy about these in-the-trunk-but-not-tagged
features ?
Yes, why not ''require 0.10''. Of course, the ideal solution would be to
write <<require 0.10>> (hint hint :) )
-- Christian
_______________________________________________
Trac-dev mailing list
[email protected]
http://lists.edgewall.com/mailman/listinfo/trac-dev
