We're evaluating scroll versions for our product documentation and can see how we can publish spaces for each new release - the publish to new space page asks for the version to publish and a space name for this new version.
However we'd also like a top-level confluence space for the main website (this could be managed by scroll versions or perhaps a more light weight process). We would have, for example, a product page that describes and links to the documentation for each product. Confluence has the KEY:page way of doing this linking.
But if the products page links to PROD010:top-level and we then create 1.1 of product and publish to a new space (say PROD011) then this link from the product page becomes out of date.
The workflow model here: https://www.k15t.com/display/VSN/Multi-Version+Support#Multi-VersionSupport-background refers to an Atlassian blog posting: http://blogs.atlassian.com/2010/11/technical_writing_wiki_documentation_release_management/ but the process used by Atlassian involves having a fixed space key for the current version and using version specific keys for the old version (so JIRA, JIRA041, JIRA042 in their example).
Linking to the "current release space" makes sense, but the publish to new space is directing us to create a new space key for each version.
How should we handle this? Should we publish a product new version twice perhaps? Once a to a new version specific space 'PROD012' and also to the existing 'current space' (PROD) ?
Atlassian's blog post talks about web server redirects. But I can't see that being very friendly when trying to create inter-space links.
Any other suggestions for handling this case?
Please sign in to leave a comment.