A great way to start managing space changes is by creating an initial space for your documentation. For example: "1.0". Your team can work together in the 1.0 space writing documentation for your initial product release.
- Once release day hits ( 🎉), it's time to begin writing content for the next major version or your product. For example: 2.0.
- To make sure you don't add any 2.0 content in the 1.0 space, copy the 1.0 space and name the copy "2.0".
Your team can now work from your already great collection of content to document all the new features in the next version of your product.
To lock the 1.0 space so your team can't make any changes to the documentation, for the space, revoke the Add Page permission from all team members. Then, grant the Add Page permission to a group with no users in it. Learn more about space permissions.
Sometimes smaller product versions are needed between major ones. For example, perhaps there was a software bug in 1.0 and it needs to be released sooner than 2.0. In this case, the team might release a 1.1 version of your product with the bug fix. In this case, the bug fix is included in 1.1 and 2.0, but not 1.0, so you'll need to make sure the changes are documented only in the correct versions.
- In this case, copy the 1.0 space and name the copy "1.1".
- Your team can now add information for the bug fix in this space and publish it to all customers getting the bug fix.
- Your team will also need to add information for the bug fix to the 2.0 space.
Keep in Mind
- This approach of creating a new space for every version is a great way to keep the content for each major change separate.
- If your team works with multiple products, or even one product with many minor releases between major ones, this approach can be very cumbersome, as you will need to ensure you make changes in all necessary spaces.
- This approach also has the downside of space URLs changing with each new version.
Write in an Authoring Space and Move for Publishing