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 spaces of the entire documentation set (i.e. camel.apache.org/2.7, camel.apache.org/2.8, ...) - use versioned spaces only for places in the content that require them (i.e. the landing page for a component is just a list of versioned children) - some other way Once you figure that out, you can figure out a way to implement it. Confluence can be used to do any of the things I suggested. Using versioned copies would not be pretty, but it would be doable. Using SCM would also work, but IIRC there were discussions that moving content into SCM would make it harder for people to participate because access to the SCM requires more karma than access to the Wiki. My preference would be for either versioning the entire documentation set for each x.x release and just adding the back ported features to the proper versions. But that is a userish preference. Managing that could be more work than is practical for the community. Just my 2 cents, Eric On Sun, Jan 15, 2012 at 6:55 AM, Christian Müller < christian.muel...@gmail.com> wrote: > 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 Camel manual. For the Camel 2.7.x > branch the actual uploaded manual is 2.7.0. I guess the reason is if we > upload the actual manual we mention also new features which we introduce in > Camel 2.8.x, 2.9.x and 2.10.x which is puzzling. But this means also that > our users cannot find new features/improvements we back ported into the > older branches. More than only annoying... > > A few times I read "we will solve this by putting the documentation into > our SCM", if I remember right. > - Do we have concrete plans to solve it? > - What are the plans in detail? > - When do we plan to solve it? > > Thanks in advance for your ideas, > Christian > -- *Eric Johnson* Principle Technical Writer | FuseSource Corp. emjohn...@fusesource.com | fusesource.com office: (781) 280-4174 skype: finnmccumial | twitter: @finnmccumial blog: http://documentingit.blogspot.com/
