How to tag muliple wiki pages (I might add with attachments) to a single release?

[Kamesh Kamesh]

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

[Andrew Frayling]

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.

[Kamesh Kamesh]

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

[Renjith Pillai]

@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.

[Andrew Frayling]

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.