Let's say I have 14 days sprint iterations where I have several stories for new features, few improvements and some bugs to fix. I also deploy those changes when they are ready, I'm not waiting for end of sprint.

My problem is - how to track semantic versioning of products developed and maintained like this? If there will be release every 14 days it will be easy, I will increase version number and note all changes in changelog. But what if changes are deployed continuously? Should there be version increased everytime something is deployed? Or should I wait until sprint ends and after this, make some "resume" and increase version number just once per iteration independently on actual deployment? What are best practices for semantic versioning in Agile?

EDIT: To better explain my needs, I want changelog for stakeholders in a first place. I don't think they will be interested in new record in changelog after every change deployed.


4 Answers 4


For typical release management, you will want a build number being generated by your build system so that the DLLs are versioned every time they are deployed. This will ensure you can later check which version is deployed on a given server.

Your 'marketing' version, which is usually put in release notes or published to your site should not be updated each version. Those release notes should be accumulated and grouped together, likely timed with the end of your sprint.

  • Yes, this "marketing" version of changelog is exactly what I need. Make it easily readable even for non-technical stakeholders. Commented Aug 21, 2015 at 16:23

If the classic semantic versioning scheme "MAJOR.MINOR.PATCH" makes sense, depends on to whom you deploy, and especially when and how often you deploy to the end user. The scheme is most useful if you work with stable release "4.5", where you start with as 4.5.0. The versions 4.5.1, 4.5.2, and so on contain only bug fixes, whilst you internally already work on version 4.6.

For example, if you provide a "stable branch" to your end user, give it a version 4.5.0 for the initial deployment, and 4.5.1, 4.5.2 whenever you release a patch. In your internal "agile" development and mid-sprint deployment, you can already have a version 4.6, just call it a "beta version". Whenever you deploy it in mid-sprint, add the auto-generated build number like "4.6.beta build 123". When your sprint ends, assign it "4.6.0", and switch the version number for the next sprint internally to "4.7". Starting with ".0" is only a convention, you can also use the ".0" for tagging beta-versions, and start with ".1" for your end users. IMHO the word "beta" is much more expressive, telling everyone the sprint "is not completed yet".

If you release a full end-user change log with each beta version is up to you, but at least at the end of the sprint the change log should be completed, and whenever you provide a bugfix to the end user, you should also update the history documents.

You will find the strategy of releasing two separated branches, one "stable" branch with semantic version numbers, and a "development branch" marked with build numbers or something similar, in lots of open source products like Inkscape, Firefox or 7-zip.

If, however, you do not work with separate stable and development branches, and release a new version to you end user daily, you should also increment a version number daily. For such a case, the version numbers "4.5.1", "4.5.2", ... will probably reflect your individual deployments, and do not indicate the difference between bug fixes and other changes. That can be ok, it is just not classic "semantic versioning" any more. In this scenario, you could also deploy versions 4.5, 4.6, 4.7, 4.8, that gives no real difference.

Concerning your question about entries in your changelog: IMHO when something is visible to the end user, it is worth an entry in the changelog, as soon as you deploy the change. For example, if you use feature toggles and make changes to some half-baked feature which is not activated yet to the user, that does not belong into a changelog. If you do only refactoring, with no visible change to user, that does not belong into a changelog. If you fix a bug which could have affected some users, that belongs definitely into the changelog - and it should be mentioned there at the same time when you deploy the bugfix. And it does not matter if you release daily or monthly or yearly.


I would use build numbers. Usually a build number would correspond to the highest version of the version control system. If mondays build number was 1745 and there has been checked 5 changes in during tuesday, tuesday evenings build number would be 1750.

Then make a short summary for what has changed between 1745 and 1750.

Then every time you update the version number of your system you can add up all the short summaries from the builds to get the changes from the last version number to the new.


My preferred method which I have been using for at least a few years now is to bump up the number after each story is completed. This means that the versions released at the end of the sprint will not be continuous, e.g. after 1.2.3 you might find 1.5.2 rather than 1.4.0.

In the changelog you may either list the intermediate versions with their corresponding descriptions or just group all changes into the "released" version and skip the versions in between.

Initially, I was afraid users would find the "holes" between version numbers problematic, but once they know about it, it is not an issue in practice. The big advantage is that increasing the number after each story makes the process less error prone - you don't have to check the whole work from 2 weeks to decide what next version number will be - when looking at a single story, it is obvious. Additionally, the "leaps" in version numbers between each release give a rough estimate of how many changes went into the release. All in all, I have found this system to work well (this was with company-internal customers, but if you already work in an agile release cycle it should work for external customers as well).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.