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?
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!
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.