How to build knowledge base for major releases of a product?

[Susi Moser]

We support multiple version of our products (like product-A version 1.1, product-A version 2.1, product-A version 3.1, …). Not all our customers use the same/latest product version.

The confluence user guide suggests to publish new spaces to document every major releases of a product: https://confluence.atlassian.com/conf54/confluence-user-s-guide/advanced-and-special-uses-of-confluence/developing-technical-documentation-on-confluence-wiki/managing-the-life-cycle-of-your-technical-documentation

But do I assume rightly, that it is only possible to link one confluence space to your service desk project?

If I can't link more than one space, which would be the best way to build a knowledge base within a service desk project to support different versions of a product?

We would appreciate receiving any suggestions! :-)

[Boris Berenberg - Atlas Authority · Accepted solution]

Your assumption is correct. There isn't a great way to do what you're describing without setting up a new service desk for every single release. I would suggest you create pages which are sectioned by version and allow users to pick the version once they search drives them to it.

[Susi Moser]

Hi Boris! Thank you very much for your suggestion. :-)

[Markus Raab]

We have pretty much the same situation, but I can't really say that the suggestion with building a page tree (one page for each major version) is a good idea.

There are KB entries that are valid for multiple product versions - it would be impossible to maintain > 10 entries for the actual same thing. The same would occur when using different spaces for different versions. And I also agree, as it is not possible to link several Confluence spaces to a single Service Desk, that this is a problem anyway.

Actually I do not understand at all why I am not allowed to link several KB spaces. To me it makes sense to keep as much as possible in one single Service Desk project (I would only need several Service Desk projects if I want to clearly separate customers (or other stakeholders)).

I personally thought about using labels to indicate the compatibility to a version, however I am not happy with that solution either. 

@Susi Moser Did you come up with a good solution?

[Boris Berenberg - Atlas Authority]

Markus, you're absolutely right, but that is the reality we work with.

One thing to remember is if a single page applies across versions. You can create a shared space with open permissions, author the shared pages there, and use the include macro to put them into the various versions. That way you only need to update the core document in one place. 

[Markus Raab]

Thank you @Boris Berenberg - Atlas Authority - this way of working sounds just so 1990s, but I agree I did not come up with anything better yet.

I will check if there are some general suggestions and/or check how other solutions are dealing with such a requirement. I don't think we are the first who have customers with different product versions installed.