CXF's website is being moved over to a buildbot build with the results being
checked in to SVN. When that is complete (filed the initial INFRA request
yesterday), we'll at least be able to tag the docs that were "current" for any
release. It's a bit early to move the Camel site to the same
If we just apply the bug patch on the branch, it will more easy for us
to maintain the document.
In this case, we can reuse the Camel 2.8.0 doc for all the other Camel
2.8.x ...
On Wed Feb 8 15:02:55 2012, Christian Schneider wrote:
I would also try to keep the documentation as simple as possi
I would also try to keep the documentation as simple as possible.
Documentation is often maintained by different people than the
developers. Currently we have the advantage that people
can help with the documentation without being developers. This is an
easy way to do first steps in camel. Using
I'm not sure that needs to be done -- the documentation should be
relevant for the latest version of each branch (2nd digit) of Camel.
So in your example below, the documentation should just state what is
available in the latest versions of each branch--i.e., 2.7.5, 2.8.3,
2.9.1, etc.--and not
Christian,
Putting the content in an SCM will not really solve the problem.
The first thing that needs to be answered is: how do you want to present
the version specific information to the users?
- the way it is now
- provide tables for all of the version specific stuff
- use versioned s
At present it's really hard to document new features/improvements which we
back port to older Camel releases. Eg. we have to mention an option is
available in 2.7.5, 2.8.3, 2.9.1 and 2.10.0+ but not in 2.8.0, 2.8.1, 2.8.2
and 2.9.0. This is really puzzling.
Another "issue" I realized today is the
