versioning

So, libbenchmark contains the older versions of the library (from 7.0.x onwards) so you can see how well the older versions are performing compared to the current version.

This leads to a problem where the current version can compile and run on more platforms than older versions, and this comes down to differences in the porting abstraction layer.

Deciding what to do with the abstraction layer is a bit problematic.

There are two reason for change;

1. bug fixes
2. ensuring older library versions can compile with the current benchmark app

The policy with regard to bug fix releases is of course bug fixes only.

This is not compatible with the sometimes major changes needed to work with the current benchmark app (such as adding new platforms).

The latest version may well have significant modifications (internal improvements), not just additions (new platforms).

We could imagine having two branches, one with bug fix changes only, one with an up-to-date abstraction layer for libbenchmark, but this is getting more complex for the user and also the current versioning system does not properly support this.

I begin to realise versioning systems are a straightjacket. It seems problematic to encode everything in them, but anything you can’t encode can’t happen in your source control system.

I have for a while (and originally did) have an integer version which simply increments. When you have branching, you then need something on your web-site to provide information about which version is which.

Problem is anything which isn’t directly obvious is going to lead people to mistakes.

Pick your poison.

I think what I may do is keep a private branch for libbenchmark.

Users won’t know about it, so it won’t muddy the waters.