Alex headshot

AlBlue’s Blog

Macs, Modularity and More

Tip of Trunk versus Versioned Releases

2013, git, java, osgi

There’s two distinctly different forms of software development at large today, and both are put to use successfully in open-source projects and at internet scale companies like Google and Twitter. These are ‘tip of trunk’ and ‘versioned releases’.

This isn’t about the different types of project management specifically; agile processes can be used for both, for example. It is perhaps more to do with where the software will end up being used; for a single (or internal) customer, tip-of-trunk can provide additional agility; whereas for libraries or customer managed products, versioned releases are more common.

Tip of Trunk

Tip of trunk development (anachronistically named, since SVN is effectively dead and trunk has long been replaced by master) is the process whereby an application or a product is in continuous development, and often continuous deployment as well. In these cases, an application is never released with a specific version number, but the application is built and then at some point cut and deployed to the production systems.

Since the open source world has migrated to Git, some developers are using the Git hash as a proxy for a version number, often combined with some form of date, deploying pseudo versions like 201308270900-c82a410 and 201308270905-1ead9d, such that there is a monotonically increasing version keyed on date/timestamp, and the hash is a record of the build state at the time.

Git tags recording versions are therefore not required; the ‘version’ uniquely identifies where it came from in any case and the roll-forward mentality means that you don’t need to back port bugfixes to earlier versions.

It may be the case that branches are used to record different states of the repository; for example, it’s conventional to have a ‘last known good’ branch that only gets updated once the current deployment has been known to be successful for some time. This allows the reconstruction of the source that is deployed, provided that such symbolic branches get updated when code is deployed. For more agile deployments, the git reflog may be used to indicate what the state of a particular branch was at a given time.

In a tip of trunk deployment model, problems are almost always resolved by rolling forward. That is, instead of the state of the system being reverted to an earlier point in time, the buggy code is reverse committed (such as with git revert). This is especially the case when working with a live git repository, as subsequent commits may have been added that should not be reverted; and since a git repository is tagged/versioned repository-wide, it is not possible to undo a small subset of the repository.

Tip of trunk development is used by companies like Facebook and GitHub, and used very successfully. However, it is an anathema to those who use:

Versioned Releases

Versioned releases are used when a version number, often consisting of a set of numerical digits, are used to represent releases of a particular product. These version numbers are ordered, which allows an easy comparison to be made of two releases to find out which is ‘more recent’.

In versioned release deployments, a release is often planned at the end of a cycle or iteration, and typically that version number is defined at the start of the iteration itself. Such versions may be minor increments (adding or fixing features) or major increments (typically having some disruption to use).

Versioning is taken care of with a versioned branch strategy. It may be that tags are used to indicate where the cut of a version was taken, but it’s quite likely that a branch is created for the 1.x or 2.x development efforts as well.

The reason why branches or tags are made for a given release are to support patching of known bugs to earlier releases. If a security vulnerability has been found with version 2.3.4 of a product, then it’s quite likely that version 1.2.3 of a product will have the same security flaw. In those instances, it is desirable (for users) to have that fix back-ported to the earlier version (say, 1.2.4) so that they are not vulnerable, even if they are unable to upgrade to the latest 2.x branch.

One of the key distinguishing features of tip of trunk and versioned releases is that the former almost universally only has one customer for the product; the organisation that is driving it forwards. GitHub has only their own site to maintain (though they do have versioned cuts for their enterprise offering) and so can afford to deploy frequently to the site without having the flow interrupted by the runtime. Versioned releases are used by developers who have multiple customers, whether it be operating systems or shrink-wrapped products (though that is itself an anachronism; software is almost entirely electronically delivered with no packaging these days).

Versioned releases bifuricated in the last decade or two, splitting into semantic versioning and dated or code word releases; for example, Windows 3.1 → Windows 95 → Windows 2000 → Windows XP.

The general trend is that applications moved towards dated releases, whilst code libraries tended to move towards semantic versioning. One of the key reasons for this is that libraries tend to be used by many different products, and whether or not the new library is compatible with the old plays a key part in deciding whether to upgrade the library or not. On the other hand, applications generally aren’t compared from a compatibility perspective via code, but rather data. As a result, Word 2001 can open documents created by Word 97 and Word 95; in this case, the document compatibility is the key factor.

Libraries tend to use semantic versioning to represent compatiblity between versions; major versions are generally incompatible, whilst minor versions are generally compatible with each other. For runtime systems like OSGi, where each module is versioned (and imports can be constrained by those versions), the correct versioning is an essential part of the system.


Both versioned releases and tip of the trunk releases are used by large-scale organisations, and both approaches work. Versioned releases tends to be used by libraries and other code which is embedded into multiple different products, whereas tip of the trunk releases often works where the development and deployment are heavily correlated, such as for internal development projects.

Neither one is right or wrong, but the approach used tends to be a function of where it is used, and how agile the project development process is.