Versioning

While we use semver under the hood for the version bumps, the versioning itself doesn't follow the semver standard you might be used to from e.g. npm libraries. This is, because we thing the logic doesn't make much sense in the context of web apps (there are no breaking changes, because we always serve the latest version to all users anyway, this obviously would be completely different e.g. in the context of a native application, where you might want the users to be able to opt out of updates that might break e.g. integrations with other apps).

So why version at all? Because we think versioning can still be useful for other things, e.g. bug tracking. Instead of increasing the version according to the type of changes, we think on app level it makes sense for the versions to represent the environment. At rexlabs we usually have multiple deployed environments, based on different branches. Besides the normal production (= master), we might have another beta deployment for early access for certain users (= i.e. beta branch) and another staging enviroment for internal testing before public releases (= i.e. alpha branch). Having versions represent these enviroments it becomes easier to track down when an issue was (most likely) first introduced by checking the version of its first occurrance.

So, instead of looking at the commits to determine the next version, kraken looks at the current version and bumps it depending on the branch it's running on.