How do you document small updates that don't meet the definition of a release?

Dan W_kamf5a

As a company we are currently engage in a digital transformation of our systems.  As part of that we are redesigning our release strategies and documentation processes.  We are struggling with how we document small, limited impact changes to code and data that doesn't qualify as a product release, in a way that is transparent to the org, and easy for the development teams to use.  Curious on ways other companies are documenting these updates?

Charlie Misonne

Hi @Dan W 

So a product release in your context is a release with a significant amount of changes or changes that are important enough to make the organization aware of it?

Anything that changes in your product, small or big, is a release. So I agree that you should have a trace of this somehow.

Usually there are different levels of releases.
A classic example is: platform release (X) - feature release (Y) - bugfix release (Z)
It translates to a naming convention like: X.Y.Z
So you'll have release version numbers like: 9.12.15
This is actually how Atlassian deals with their versions for their own releases.

You can also have 2 levels: major release - minor release

In Jira you can add those releases at the project level and use them in the "fix version" field in order to track in which version something is released.
And this can be used to generate release notes to spread across the organization or put on a Confluence page.
You could chose to communicate about platform and feature releases and not about bugfix releases for example.

I hope this helps and that I understood your question right!