## Preparing the project for a release
Before you create a release in Atloria, make sure the project itself is ready. Start from the project workspace and review the project settings that affect publishing, especially the current default version and any website or public documentation options already tied to the project. If the wrong version is marked as the main reader-facing version, your release can go live with the wrong entry point or confuse reviewers who are checking the version selector.

Next, confirm that the right people can participate in the release. In Atloria, release work usually involves people with responsibilities such as **Documentation Manager**, **Project Administrator**, and **Technical Writer**. Check the user access area and confirm who can create versions, who can review and approve content, and who can publish to the public documentation experience. If a reviewer is missing access, fix that before the version is generated so approvals do not stall later. For broader access checks, see [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions).

Then inspect the draft documentation set itself. Open the page tree and look for pages that are still incomplete, pages with unresolved comments, and pages that have edits that were never finalized. A clean release starts with a clean draft. If you already use a structured publishing flow, keep this aligned with the release coordination steps in [Coordinating Project Publishing From Draft to Public Release](doc:coordinating-project-publishing-from-draft-to-public-release).

Before moving on, verify the release inputs you plan to use:

| Release item | What to check |
|---|---|
| **Version label** | Make sure the name matches exactly what readers should see |
| **Release date** | Confirm your team is using the correct target release timing |
| **Publication scope** | Check which pages, sections, or audiences are meant to be included |
| **Source workspace** | Confirm you are releasing from the correct draft or approved content set |

[SCREENSHOT: Project workspace showing settings, default version, and release-related controls]

## Updating draft content before versioning
Once the project is ready, clean up the draft content that will feed the release. Open the draft pages in Atloria’s document editor and review each page title, description, slug, and navigation label. These details shape how the release appears in menus, search results, and shared links. If a page title changed during drafting but the navigation label did not, fix that now so the published navigation stays clear and consistent.

Use the page tree to spot structural changes. Pay close attention to pages that were recently added, moved into a different section, or renamed. A release can look incomplete even when the content is correct if the page tree still contains outdated labels or misplaced pages. If your team has been reorganizing content heavily, compare the current tree against the intended reader journey and make sure the landing pages still point readers into the right sections.

Review feedback is just as important as the page text. Open pages that show comments, review markers, or approval indicators and resolve anything that should not carry into the release candidate. If a page still has open discussion about wording, screenshots, or missing steps, settle that before creating the version. For more detailed review workflows, use [Reviewing and Approving Documentation Versions](doc:reviewing-and-approving-documentation-versions) and [Understanding Version Review Feedback and Follow Up](doc:understanding-version-review-feedback-and-follow-up).

Finish by checking links and assets inside the draft. Open key pages and test internal links, screenshots, and references to version-specific material. Watch for links that still point to older versions, draft-only pages, or outdated section names. If you use screenshots in release content, this is a good point to verify they are current and available in the right project context.

1. Open the draft page from the page tree.
2. Update the page content and metadata fields.
3. Check comments and approval markers on the page.
4. Test links, screenshots, and references.
5. Repeat for all pages included in the release.

[SCREENSHOT: Draft page open in the document editor with page tree, metadata fields, and comments visible]

## Generating the release version
When the draft is ready, move to the version area in Atloria and start the version creation workflow. Use the project’s release controls to create a new version, then enter the version name exactly as it should appear to readers in the version selector. This is not just an internal label. It becomes part of how teams and public readers identify the release, so check the spelling, numbering, and formatting carefully before you continue.

Atloria may let you choose the source for the new version. Depending on how your team works, that source may be the current draft workspace or an already approved documentation snapshot. Choose the source that matches your release plan. If your team completed a formal review cycle, use the approved content source rather than a draft that may still contain late edits. If you need help deciding between active draft content and a locked review state, refer to [Managing Documentation Versions Across the Release Cycle](doc:managing-documentation-versions-across-the-release-cycle).

As you continue, review what Atloria is carrying into the new version. The version creation process copies the page structure, navigation setup, and page details that define the release. This is the point where writers should understand what is being frozen into the release version and what remains editable in the ongoing draft workspace. That distinction matters when someone notices a typo after the version is created—fixing the draft alone may not update the release candidate you just generated.

After the version is created, confirm it appears correctly in the versions list. Check the new entry for the version name, its release status, and any indicators showing whether it is still in review, approved, or ready for publication.

1. Open the project’s version or release controls.
2. Click the option to create a new version.
3. Enter the new version name exactly as it should appear.
4. Select the correct source content.
5. Finish the creation process.
6. Open the versions list and confirm the new version entry appears.

[SCREENSHOT: Version creation screen showing version name field, source selection, and confirmation view]

## Reviewing the release and validating access
After the version is generated, review it as a release candidate rather than assuming the draft carried over perfectly. Open the new version in preview or review mode and compare the most important pages against the draft source. Start with the landing page, top-level navigation groups, and any high-traffic pages your readers rely on first. This helps you catch missing sections, outdated page labels, or content that was still in progress when the version was created.

Access validation is just as important as content review. In Atloria, a version can include pages with different visibility rules, so check whether internal-only pages, restricted sections, and public pages are appearing for the right audiences. If your project uses audience targeting or controlled access, test the release with the same visibility expectations you plan to use after publication. Helpful background is available in [Managing Version Visibility and Reader Access](doc:managing-version-visibility-and-reader-access) and [Publishing Documentation for Specific Audiences](doc:publishing-documentation-for-specific-audiences).

Also test the version selector and page links. Open several pages from the generated version and confirm the URLs lead to the intended release, not back to draft content or another published version. If inherited permissions are part of your setup, make sure they still behave correctly after version generation. A page that looks fine to an editor may still be hidden from the wrong audience after publication.

Before you move to export or publication, collect final sign-off from the required reviewers. Check the approval indicators tied to the version and confirm that every required reviewer has completed their part.

1. Open the generated version in preview or review mode.
2. Compare key pages and navigation against the draft.
3. Test visibility for public, restricted, and internal content.
4. Check the version selector and page links.
5. Confirm all required approvals are present.

[SCREENSHOT: Version review screen showing preview, approval status, and version selector]

## Choosing whether to export or publish directly
Once the version is approved, decide how you want to deliver it. In Atloria, you may publish directly to the public documentation experience or create an export for controlled distribution. Direct publication is the right choice when readers should access the release through the public site, browse it with normal navigation, and switch versions using the version selector. Export is more useful when the release needs to be shared offline, archived, or distributed outside the public documentation portal.

If you choose export, review the available export settings carefully. Check the output format, the pages included, and the version scope so the exported package matches the approved release. A common mistake is exporting only part of the documentation tree or using the wrong version when multiple versions are available. If your team relies on export workflows often, see [Managing Export Workflows for Documentation Records](doc:managing-export-workflows-for-documentation-records) and [Validating Export Readiness for Documentation Versions](doc:validating-export-readiness-for-documentation-versions).

Your choice also affects how readers experience access. A public release is discoverable through the published documentation area and follows the visibility rules configured for that version. An exported package is distributed separately, so readers do not use the same public navigation, version switching, or audience-based browsing experience. That difference matters if your stakeholders expect the release to behave like the live documentation site.

Before final release, verify the output. For direct publication, use the publication preview if available and click through navigation, landing pages, and assets. For exports, open the generated output and confirm formatting, screenshots, and links behave as expected.

1. Decide whether the release should be public or distributed as an export.
2. If exporting, choose the correct format and included content.
3. If publishing, review the public-facing version preview.
4. Validate navigation, links, and assets before final release.

[SCREENSHOT: Export or publish decision point with version scope and preview options]

## Publishing the release and fixing common issues
When the approved version is ready, publish it from the version or release controls in Atloria. After publishing, confirm that the version appears as the intended visible release in the project’s version list and, if your project uses public documentation, on the public landing page. Open the published view and make sure readers are seeing the correct version first, especially if this release is meant to replace an older default version.

If pages are missing after publication, start by checking whether those pages were actually included in the version snapshot. A page can be absent because it stayed in draft-only status, was excluded before version creation, or was hidden by navigation settings. Open the versioned page tree and compare it with the draft tree you reviewed earlier. If the page exists in draft but not in the released version, you may need to update the draft and generate a corrected version rather than editing the already published release.

Access problems usually show up when reviewers can see content but public readers cannot. In that case, recheck visibility settings, audience rules, and public access configuration for the released version. If the project uses restricted sections, confirm those sections were not accidentally applied to pages that should be public. Related guidance is available in [Validating Version Access Before Sharing or Export](doc:validating-version-access-before-sharing-or-export).

Broken links and missing assets are the other common post-publication issues. Open the affected page in the published version and test every version-specific link, screenshot, and attachment reference. If an asset was available in draft but not in the release, confirm it was included in the published version and not tied only to an earlier draft state.

1. Publish the approved version.
2. Open the public or released view and confirm the visible version.
3. Check for missing pages in the released page tree.
4. Recheck visibility and audience settings if access looks wrong.
5. Test links and assets on key published pages.

[SCREENSHOT: Published version view showing version list, public landing page, and released navigation]

## Overview
This guide focuses on the release stage of documentation publishing in Atloria: taking prepared draft content, turning it into a versioned release, validating access, and making the release available either through publication or export. It assumes your team is already working inside a project with draft documentation in progress and that you are close to the point where readers should receive a stable release.

The workflow here is narrower than the broader publishing process covered in [Publishing a Project from Setup to Public Release](doc:publishing-a-project-from-setup-to-public-release). It also builds directly on [Coordinating Project Publishing From Draft to Public Release](doc:coordinating-project-publishing-from-draft-to-public-release), where the focus is on aligning people, timing, and review decisions across the release cycle. This document picks up at the moment when the content is nearly ready and you need to run the actual release steps in the correct order.

You will work across the parts of Atloria that matter most during release:
- The **project workspace** for release readiness checks
- The **document editor** and **page tree** for final draft cleanup
- The **versions list** and release controls for creating the release version
- **Preview** or **review mode** for checking the generated version
- **Export** or **public publication** options for final delivery

Use this guide when you need to answer practical release questions such as:
- Is the draft clean enough to version?
- Which content source should become the release?
- Are the right people able to approve and publish?
- Should this release be exported or published directly?
- Why is a page missing or hidden after publication?

If you are already inside a version workspace and need deeper help with status handling, comparisons, or approvals, the related version guides in Atloria’s documentation set will be the best next reference.

## Prerequisites
Before you follow this release workflow in Atloria, make sure the project and team are already set up for versioned documentation work. This guide does not cover first-time onboarding, repository connection, or initial project setup. If you still need to prepare the project itself, use [Creating Projects and Completing Onboarding](doc:creating-projects-and-completing-onboarding) and [Choosing Between Manual and Connected Project Setup](doc:choosing-between-manual-and-connected-project-setup).

You should have the following in place:

- A project with an active draft documentation set
- Access to the project workspace and document editor
- Permission to create versions, or a teammate who can do it
- Reviewers assigned for approval decisions
- A clear version name and release target
- Agreement on whether the release will be published publicly or exported

It also helps if you have already completed these checks:
- The page tree reflects the intended published structure
- Important pages have current titles, descriptions, and slugs
- Review comments have been addressed on release-bound pages
- Audience or visibility rules have been reviewed for the release
- Screenshots and linked assets are available in the content you plan to release

If your role is mainly administrative, you may want to confirm organization-level access and publishing permissions before starting. These topics are covered in [Using the Admin Workspace](doc:using-the-admin-workspace) and [Managing Organization and Admin Settings](doc:managing-organization-and-admin-settings).

If you are ready to move beyond publication and start evaluating how readers use the released documentation, continue with [Using Analytics to Prioritize Documentation Improvements](doc:using-analytics-to-prioritize-documentation-improvements).