Release Notes

What Is a Release Notes Template?

A Release Notes Template is a structured document used by software developers and businesses to communicate changes, updates, and fixes to their users. It serves as a formal record of what has changed in a specific version of a software product, mobile app, or digital platform. While it is a technical document, it acts as a bridge between the development team and the end user.

For Australian businesses, this template is more than just a list of updates. It is a communication tool that manages customer expectations and fulfills certain legal obligations. Whether you run a SaaS company in Sydney, a tradie app developer in Melbourne, or a startup in Brisbane, using a standard template ensures consistency. It helps you clearly outline new features, bug fixes, and known issues.

In the context of Australian professional standards, a good template aligns with industry practices like Semantic Versioning. This system uses a version number like 2.1.0 to instantly tell the user if the update is a major change, a minor feature addition, or a simple patch. By using a template, you ensure that every time you push an update, you include the necessary version identifiers and legal disclaimers to protect your business.

When to Use This Document

You should use this document whenever you deploy a new version of your software or digital product to users. This applies to public releases, beta testing phases, and internal updates for enterprise clients. Even if the changes seem small, documenting them is good practice.

For B2B software providers, such as those creating job management tools for tradies, release notes are critical. Users in the construction and trades sectors rely on software for safety-critical calculations and invoicing. If you update a calculation engine or change how GST is handled, you must notify them. A template helps you do this efficiently.

You also need these notes when you are making changes to how you handle user data. Under the Privacy Act 1988 (Cth), transparency is key. If a software update alters how personal information is collected or stored, the release notes are the appropriate place to flag this change.

Businesses should also use this document when phasing out features. If you plan to remove a function that your clients currently use, you must provide advance notice. This is often referred to as a deprecation notice. It helps you avoid claims of disrupting a user's business operations.

Key Sections and Required Elements

A professional release notes template needs specific sections to be legally sound and practically useful. These elements ensure the user understands exactly what is happening with the software.

Version Identifier & Release Date

Every set of release notes must start with the version number and the date. Most Australian developers follow Semantic Versioning (SemVer). This looks like v1.0.0 or v2.1.3.

• Major version: Incompatible API changes or major overhauls.
• Minor version: New functionality added in a backwards-compatible manner.
• Patch version: Backwards-compatible bug fixes.

The date is crucial for liability timelines. It helps establish when a defect was fixed or when a new feature became available. This is important if a dispute arises later about software performance.

Description of Changes

This section forms the body of your document. It should be split into clear categories.

• New Features: List any new capabilities. Be precise about what the software can now do. This sets the expectation for the product's fitness for purpose.
• Bug Fixes: Detail any errors that have been resolved. It is not enough to say "general fixes." You should specify what was broken and what is now fixed. This shows you are maintaining the product.
• Known Issues: You must list any bugs that persist in this version. This is a vital legal defense. If a user experiences a problem that you have already listed as a known issue, they cannot claim the software failed to meet consumer guarantees for that specific fault.

Breaking Changes & Deprecations

This section warns users about changes that will disrupt their workflow. A "breaking change" alters the way the software works so that previous methods no longer function. "Deprecation" means you are warning that a feature will be removed in the future, usually within 30 to 90 days. Providing this notice is essential to uphold consumer guarantees regarding the continued use of the service.

Legal Disclaimer

Every template needs a disclaimer section. This text should clarify that the software is provided "as is" and that forward-looking statements about upcoming features are not guarantees. This helps limit liability under the Corporations Act 2001 (Cth) and the Competition and Consumer Act 2010 (Cth).

How to Write a Release Notes Template (Step by Step)

Creating a robust template takes a bit of planning. Follow these steps to build a document that works for your Australian business.

Step 1: Set the Header

Start with a clear header. Include your company logo and the document title. Below this, create fields for the Version Number and Release Date. Using a standard format here helps with software maintenance standards.

Step 2: Define the Summary

Write a brief one-paragraph summary of the release. This is the "elevator pitch" of the update. Keep it plain and simple. For example, "This update introduces a new invoicing dashboard and fixes several issues reported by our users in Queensland."

Step 3: Categorise Your Updates

Use clear headings for New Features, Improvements, and Bug Fixes. Under New Features, use bullet points. Explain the value of the feature. If you are updating a software development agreement, refer to it to ensure you are delivering what was promised in the contract.

Step 4: Detail the Breaking Changes

If you have changes that will affect how the user works, put them at the top or in a dedicated warning box. Use bold text. You need to ensure the user sees this before they read about the nice new features. This is about managing risk and maintaining trust.

Step 5: List Known Issues

Be honest here. If there is a glitch with a specific browser or a minor issue with a report export, list it. This transparency protects you from claims of misleading conduct. It shows you are managing the software's quality openly.

Step 6: Add Privacy and Accessibility Notes

If the update changes data handling, add a specific note about privacy. Reference the Privacy Act and explain that users should review the updated policy. Also, confirm that the update aligns with WCAG 2.1 accessibility standards. This ensures your notes are usable by everyone, complying with the Disability Discrimination Act 1992 (Cth).

Step 7: Include the Disclaimer

At the bottom of the template, place your legal disclaimer. It should state that features in development are subject to change. It should also reiterate that the software is intended for use in Australia and complies with local laws where applicable.

Common Mistakes to Avoid

There are several pitfalls that Australian businesses often fall into when writing release notes. Avoiding these will save you time and legal trouble.

Over-promising Features

One of the biggest mistakes is advertising a feature in the release notes that is not actually live or is buggy. Under the Competition and Consumer Act 2010, software is a "good." If you describe a feature that does not work, you are engaging in misleading or deceptive conduct. A user might pay for a subscription based on that feature. If it fails to work, you have breached consumer guarantees regarding acceptable quality. Only list what is actually working in the release.

Using Vague Language

Saying things like "fixed general issues" or "performance improvements" is not helpful. If a tradie using your app had a crash that cost them money, they want to know it is fixed. Being vague can look like you are hiding something. Be specific. Saying "Fixed the crash when exporting PDFs on iOS 16" is much better.

Ignoring State Variations

Australia has different laws in different states. While consumer law is federal, specific industry regulations can vary. If you are providing WHS software, ensure your notes acknowledge that safety features comply with the specific WHS regulations of the state where the user operates, whether that is NSW, Victoria, or Western Australia.

Forgetting Beta Disclaimers

If you mention features that are coming soon, you must label them as "Beta" or "Roadmap." Without this, users might assume these features are part of what they are paying for now. This can lead to disputes under the Corporations Act regarding financial loss if a business relies on a feature that does not yet exist.

Skipping the Accessibility Check

Release notes are often published on the web. If you publish an image of text without alt text, or if your notes are not screen-reader friendly, you exclude users with disabilities. This can be a breach of the Disability Discrimination Act. Always make sure your release notes are accessible.

Legal Considerations (AU)

Release notes are not just technical updates; they are legal documents in Australia. They form part of the ongoing relationship between you and your customer.

Consumer Guarantees

The Australian Consumer Law (ACL) provides guarantees that cannot be excluded. Software must be of acceptable quality and fit for purpose. Your release notes are evidence of what you claim the software does. If your notes claim the software integrates with a certain accounting platform, but it doesn't, you have breached the consumer guarantee. The ACCC takes a firm stance on digital products. You must ensure your release notes accurately reflect the software's capabilities.

Misleading and Deceptive Conduct

Section 18 of the Competition and Consumer Act 2010 prohibits misleading conduct. If you write release notes that hide a major bug or gloss over a security flaw, you could be found to have misled your users. This is particularly serious for B2B transactions. If another business relies on your software and loses money because your notes were misleading, you can be liable under the Corporations Act 2001.

Privacy Obligations

The Privacy Act 1988 requires you to be transparent about personal information. If a release introduces new data tracking or changes how you store client data, this must be in the notes. Failing to disclose data handling changes can lead to penalties from the Office of the Australian Information Commissioner (OAIC).

Contractual Terms

Your release notes often form part of your contractual terms of service. If you have a service level agreement with a client, the release notes define the scope of the service being provided. Removing a feature without proper notice, as outlined in your deprecation section, could be a breach of contract.

Liability Limitation

While you cannot exclude consumer guarantees for consumers, you can limit liability for other types of loss in B2B contracts. Your disclaimer section is where this happens. However, the disclaimer must be reasonable. It cannot simply say "we are not liable for anything." It must be drafted to specifically address reliance on the information provided in the notes.

Frequently Asked Questions (preview)

Do I really need release notes for small updates? Yes. Even small updates should be documented. If a bug fix changes the calculation of a tax or safety metric, you need a record of it. This protects you if an audit occurs or if a user claims a loss due to a software error.

Can I just link to an external page for the details? You can, but the key information must be accessible. If you use an end user license agreement that refers to an external website, ensure that website is up to date and accessible. However, for major changes, it is best practice to send the notes directly or have them pop up in the app.

How long should I keep old release notes? You should keep them for the life of the software version plus the warranty period. In Australia, this is often tied to the statute of limitations for contract disputes, which can be up to six years. Keeping a log helps if you ever face a legal claim about software performance.

Who should write the release notes? Ideally, a product manager or a technical writer should write them, with legal review for major updates. Developers often use too much technical jargon. The goal is to communicate clearly with the user, not just to log code changes.

What if I find a bug right after releasing? Issue a patch and update your release notes. Add the bug to the "Known Issues" of the previous version if possible, and release a new version immediately. Honesty is the best policy to maintain trust and comply with the ACL.