Okay. Avoidance of more work is a requirement. Forget all that
silliness about a common XML file format and putting extra files in
features.
Wayne
On 02/02/15 10:03 AM, Daniel Megert
wrote:
For us it would mean
more work, which I'd
like to avoid. Having one document easily allows to tools to
e.g. check
for XHTML validity, and help fix such issues. If the document is
generated
out of pieces, then it can be a tedious task to get to a
generated document
that is valid. The extension point doc is such an example: the
text for
the elements is entered in the extension point editor in
separate fields,
and during build a document is generated. If there are errors,
it's hard
to detect and fix them. Also, spell checking a single document
is easier
than doing the same over different fragments.
Another point is, that the
N&N of
a release is not simply the collection of the milestone
N&Ns. We e.g.
put the new Quick Fixes under one item for the release, or a
feature that
got developed over several milestones with entries in the
corresponding
milestone N&Ns will have to be collapsed into a single
entry.
I'd like to keep our approach for
our
project, since it works well for us, and produces good quality
N&N
documents. If other projects want to try out something new where
the N&N
is generated, and provide feedback about how it worked for them,
that's
of course fine for me too.
Dani
--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
 |
