What fix version naming convention do you follow if releasing multiple times a week within a 2 week sprint?
We are moving from monthly release to twice a week and figuring a fix version that won't cause confusion.
We use fix versions to communicate expected release of a feature or bug fix as well as progress.
Hi,
I've seen teams use a number of different conventions. It really depends on your product and preference:
This is the most common versioning convention.
The major version number is incremented when there are major changes to the software, such as new features or breaking changes.
The minor version number is incremented when there are minor changes to the software, such as bug fixes or performance improvements.
The patch version number is incremented when there are small changes to the software, such as documentation updates or security fixes.
The build number (optional) is incremented for each build of the software, regardless of the changes that were made.
This convention uses the year, month, and day of the release. This is a simple and easy-to-understand convention, but it does not provide any information about the changes that were made to the software.
This convention combines the year, month, and day of the release with the build number. This provides more information about the changes that were made to the software, but it is still a relatively simple convention.
This convention simply uses sequential numbering for each release. It's simple and easy to follow, but the drawback is that unlike Major.Minor.Patch.Build it doesn't provide any information about the impact of the changes.
Hope this helps,
Jens
@Jens Schumacher - Released_sothanks for responding
We were using major. minor but mapping that to 8+ releases a month will get tricky. Also thought that dates may get confusing in the event we did not push on a certain day and have to tweak it then.
Anyone hear of using sprint names for fix versions so you know what window the work is planned to be complete?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@bart no worries.
You certainly can use sprint names for fix versions. The disadvantage of course is the lack of meaning, specifically if you use the version names publicly.
Out of interest, what makes the major.minor mapping tricky? Most of the releases will simply increase the minor part of the version number.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I think for every ticket it would be X.y.1, X.y.2, X.y.3....X.y.8. I can picture devs with 2 weeks worth of work in the sprint not knowing which goes to which
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.