Fix version naming convention for multiple releases in a sprint?

bart_3w16uu

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.

Jens Schumacher - Released_so

Hi, 

I've seen teams use a number of different conventions. It really depends on your product and preference:

• Major.Minor.Patch.Build

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.

• YYYYMMDD

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.

• YYYYMMDD-Build

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. 

• Sequence 
  

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