For example, if I am working on a design and it spans across multiple wiki pages. Each page may contain some relavant documents attached to them. I want to be able to make a release of the design for peer review. What is the best way to create a version tag (like CVS or Subversion version control systems) to tag all the current version of the pages, so that, that tag can be reverted if needed.
If I want to move away from document centric approach to wiki style, I should be able to maintain the versions of individual pages (which COnfluence seems to do a pretty good job) and collective pages.
I don't want to throw away my old Visio diagrams yet!
Greatly appreciate your inputs.
Thanks,
--Kamesh
Hi Kamesh,
One approach that may be worth looking at is how Atlassian version their documentation, which is basicaly a space for each product version. Sarah Maddox has a detailed write up on her blog at http://ffeathers.wordpress.com/2007/11/17/wiki-docs-release-management/
It's not exactly what you're looking for, but it might be worth some investigation?
Andrew.
Thank you Andrew for a qiock response. I went through the interesting blog post. I think it would be very challenging and difficult to manage Confluence in the long run. I can see challenges with creating a space for each release cycle especially if we want to adopt to agile development where release cycles depend heavily on the sprint cycles. Even if we stick with "copy space", I guess, cross space comparison could be very challenging!!
Do you see my challenge any differently?
Thank you!
--Kamesh
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@kchalla
I would say, you should fork out the documentation per major release, not per sprint, and for per sprint changes, you could simply use a {recently-updated} to send out for review rather than taking the pain to label and unlabel everytime.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Kamesh,
I'd agree with @Renjith and only fork the documentation with each major release - which is what Atlassian do, they only fork it for public releases, not internal sprints.
One way to track per sprint might be to create a child page for each sprint, label the child with the sprint version and use content by label to pull together an index of pages for a sprint?
Andrew.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.