Write in an Authoring Space and Move for Publishing

If your team makes a product that's always on the latest version, such as a SaaS app, it may be less important for users to have access to older versions of your documentation. In this approach, you use one space to contain the documentation for your most recently released version of your product. You then work with one or more "development" spaces, where you prepare changes for upcoming major or minor versions.

Start by creating an initial space for your documentation. For example "Draft". Your team can work together in the Draft space writing documentation for your upcoming major product release.

Major Versions Documentation

1. When the first major version of your product is released, copy the Draft space and name the copy something like "Final". You will use the Final space for documentation publishing.
2. You may want to make an archive of your documentation to look back on, or for documenting minor versions in the case of a software patch. In this case, copy the Draft space and name it after the product version to which it relates. For example: "1.0 Archive".
3. Your team can now begin updating content in the Draft space for the next version.
4. When the next major version of your product is released, export the content in the Draft space and import it into the final space. This way, the Final space now contains documentation for the latest release, which you can then publish.
5. Continue the process for major releases by working on the next major version in the Draft space, and exporting the content into the Final space when it's ready.

Minor Versions Documentation

1. When you need to release a minor version, copy your most recent archive space and name the copy something like "Draft 1.1".
2. Your team can then write the documentation for the minor version in the Draft 1.1 space, and add any needed updates in the Draft space also, if the change affects both the minor and major release.
3. When the minor patch is released, export the content in the Draft 1.1 space and import it into the Final space. In this way, the Final space now contains documentation for the latest release, which you can then publish.
4. To create an archive of the minor release, change the name of the space to something like: "1.1 Archive".
5. Continue this process for minor releases by creating a copy of the most recent archive space, working on the next minor version in the copied space, and exporting the content into the Final space when it's ready.

Keep in Mind

• This approach of having one central publishing space for your documentation is ideal for teams working on products that are always up to date.
• It's also a great solution because the URL for the publishing space never changes.
• This approach introduces complexity when working on multiple minor versions at the same time, or in cases where a minor version is rescheduled to be released after a different major version.
• Your team will also need to make sure the content in multiple spaces is updated.