Hi I think we have touched this a bit before but I doubt that we have a solution for it that is easy and doesn't require too much time/effort to keep two installments of the wiki updated / in sync. So I doubt there is anyting smart we can do on the wiki front. Just that we remember to add some text which version of Camel this applies.
But we are getting the .pdf/.html manuals building now and Jonathan is working on tidying up the layout so it looks nice and cool. We just need to remember to add a links to it from a book_all_in_one_page wiki page. Using this technique we will be able to release a manual that is fixed with the release in question. So that would probably be the solution. So when the next ActiveMQ is release it will bundle a Camel release as well where the manual is included as a .pdf / .html. Feedback what to include in the manual and the manual itself is of course much welcome. http://activemq.apache.org/camel/manual.html On Mon, Dec 15, 2008 at 5:13 AM, Ramon Buckland <ra...@thebuckland.com> wrote: > I notice that this is a problem of the wiki way of doing things. > Is there a workable model where 1.5 (1.5.x) software can be documented in > isolation of any 2.0 changes. > > then 2.0 documentation includes, enhances and adds to 1.5.x documentation. > > Does confluence support anything like this ? (ie {supported version=1.5} ) ? > > The end result I would expect to see is documentation specific for 1.5 and a > separate tree for 2.0. > > At the moment I am noticing some documentation going up which is not > supported yet in any production release. > (and the automatic documentation is a problem with the Wiki looking into SVN > trunk to pull examples, not yet supported). > > An example of this being important is: > > Active MQ is 5.2.0 released with camel 1.5.0. > > So I logically, when working with AMQ want only the documentation related to > 1.5.0 as this will be the "production" release for the client. If I can see > that something I want is now available in 2.0, I can deal with it > appropriately (backport, speak to client, work around problem to use > available etc). > > There must be a better way than current (but please don't get me wrong, the > documentation is good.. much better than other products I have used! ) > > cheers > r. > > On Sat, Dec 13, 2008 at 05:45, Jon Anstey <jans...@gmail.com> wrote: > >> This element was changed to split() for Camel 2.0. I've updated the wiki >> page. Thanks for spotting this Yogesh! >> >> >> > -- /Claus Ibsen Apache Camel Committer Blog: http://davsclaus.blogspot.com/
