Find changes between software release drafts

A small wording change in release notes can alter what users expect, hide a limitation, or publish the wrong date. When two drafts look nearly identical, it is easy to miss a changed sentence among routine edits.

Use Text Compare to show where the drafts differ, then review each change in context. A comparison can reveal changed wording, missing lines, and moved content, but it cannot tell you whether a release claim is technically correct.

Compare the two drafts

1. Open Text Compare. Copy the earlier draft into one text area and the newer draft into the other. Keep the drafts separate and make sure you do not paste the same version twice.
2. Compare the texts. Look for additions, removals, and changed wording, not just large blocks of difference.
3. Start with high-impact details: feature names, supported versions, dates, upgrade steps, known issues, security statements, and links.
4. For each change that matters, check the surrounding sentences and confirm the intended edit with its owner or source document.

Use the same text boundaries in both drafts. For example, compare the complete release note section with its matching section, rather than comparing a full document against a paragraph copied from it. Extra headings or boilerplate can make the result harder to scan.

What the differences mean

A new feature or instruction appears

Added text may describe a new feature, a changed workflow, or a prerequisite. Confirm that the feature is included in this release and that each step matches the current product. Pay particular attention to commands, setting names, supported versions, and whether an instruction applies to all users or only some of them.

A limitation or warning disappeared

Removed text is not automatically harmless cleanup. A deleted warning may describe a known issue, a compatibility limit, or a condition users need to meet before updating. Check whether the underlying problem has actually been fixed. If not, restore or revise the warning before approval.

A number, date, or version changed

Small edits to numbers can have large consequences. Check release dates, version identifiers, minimum operating system versions, file sizes, and support timelines against the approved release plan. A text comparison can show that a value changed, but it cannot establish which value is correct.

A sentence moved or several lines look different

Some comparisons show a moved paragraph as a deletion in one place and an addition elsewhere. Read both sections to determine whether the meaning changed or the same text was simply relocated. A new heading or an edited line break can also make a larger section appear different than expected.

The drafts appear identical

Check that you pasted the intended versions and included the whole section in both areas. If a difference exists only in formatting, such as font size or color, a text comparison may not show it. Use the document editor to inspect layout and styling separately.

Review the changes before approving the release

1. Separate editorial edits from product claims. Fixes to spelling and punctuation are usually low risk. Changes to what a feature does, who can use it, or what a user must do need verification.
2. Check names and numbers against a trusted source. Verify version numbers, dates, feature names, and menu labels against the release build or approved product documentation. Do not rely on memory when a single digit could send users to the wrong version.
3. Read changed lines with nearby text. A sentence can be accurate by itself but misleading after a neighboring sentence is removed. Read the full paragraph, including any heading that introduces it.
4. Open changed links. Copy each changed URL into a browser and confirm that it reaches the intended page. Check links in the published format too, because a draft may contain a placeholder or an internal-only address.
5. Ask the right owner about unresolved changes. Send specific questions to the feature, support, or release owner. Include the old wording, the new wording, and the decision needed, rather than asking them to review an entire draft without direction.
6. Save the approved version clearly. Use a filename or document history entry that identifies the release and approval state. Keep the compared drafts available so another reviewer can tell which versions were checked.

Why a change can look bigger than it is

Text comparison tools work with text, not the full appearance or meaning of a document. A paragraph that moves may appear as a removal and an addition. A formatting change may not appear at all. Differences in spaces, line breaks, or punctuation can also create marks that are easy to mistake for a meaningful rewrite.

For release notes, review changed text at two levels. First, inspect the exact words that differ. Then read the whole section as a user would. This catches both subtle edits, such as a changed version number, and broader effects, such as a feature description that no longer matches its heading.

Treat the comparison as a review aid, not as proof that the release notes are accurate or complete.