Sure, it’s not perfect. It exists to satisfy two constraints: purely numeric versioning for everything, including alpha and beta releases, and preventing software that wants final versions from accidentally finding alpha or beta versions.

There is a bonus of being able to explicitly look for alpha and beta releases – useful when projects are moving forward in tandem (eg: consider alpha release of Frameworks, where *all* the Frameworks will be in alpha at the same time, and depend on each other). You make a valid point about alpha releases being incompatible with each other and with everything else, but it’s easy enough to specify EXACT in the find_project() calls of the downstreams to deal with that.

Only for built objects – it only covers binary compatibility, not source compatibility. Semantic versioning aims to cover source compatibility, rather than binary compatibility.

If you wish to have a single major version increase for the whole alpha phase, you either stop releasing alpha versions (which is not what you want), or accept the fact that the alpha is incompatible and might break at any time – in this case the used version scheme is used in a wrong way and your cmake script will not help.

Your cmake script helps when the API is freezed – in the beta phase. But it will not help in the alpha phase, where the API breaks rather frequently.

The correct way is the following – once you release a version (make it public), look at the library API as being frozen. If you break compatibility in the next version (and it does not matter if it is another alpha), you should increase the major version as well.

I need (small – 10×10 or so would be fine for most of them) files containing at least red, blue, green and white pixels at various transparencies. These need to be saved uncompressed, with RLE compression, zip (with prediction) compression and zip (without prediction) compression. I’d like a variety of colour spaces (RGB, gray, bitmap, indexed, lab, etc) and colour depths (8, 16, maybe 32, for colour spaces that makes sense for).

For RLE compression in particular, I’d like some horizontal runs of identical pixels of length 1, 2, 126, 127, 128, 129 and 130. I don’t need every possible combination of everything (that would be a ridiculous number of images), but I’d like at least one of everything (at least one file for each compression mode, at least one file for each colour depth, etc), and I’d like most plausible combinations of colour space and colour depth (although I’m not too bothered about 32-bit colour depth).

Each image would need a corresponding PNG reference image (although if a bunch of files are identical except for the compression mode, only one PNG is needed for all of them).

I might be able to dig out an old copy of Photoshop, if there’s anything missing from the Krita test files please create an issue to track it, if it benefits Krita I’ll be extra motivated to help.

Thanks, I’ll check those out.