A note on version numbers

There is an argument to be made that starting off with v0.0.1-beta (pre-release) was a somewhat overly-conservative way to version software that has been in use at Queen's University for over a year, and in development for longer.

That's probably fair. I ditched the beta quickly.

Nevertheless, the rationale behind the overall numbering scheme is based on Semantic Versioning, which describes:

Given a version number MAJOR.MINOR.PATCH, increment the:

• MAJOR version when you make incompatible API changes,

• MINOR version when you add functionality in a backwards-compatible manner, and
• PATCH version when you make backwards-compatible bug fixes.

This approach had been adopted by many projects, and has also been chosen here both because it seems eminently sensible, and also because it works well with Maven.

All versions of the form v0.0.x were flagged as 'pre-release', with the idea of using these to rapidly to iron out early bugs (and add some features).

In general, small changes will the PATCH version increase while everything else stays the same. Users shouldn't see very much difference between these versions, and nor should they expect to see analysis results run with different PATCH versions to be different (although unfortunately no absolute promise can be made in this regard... since no one developing QuPath can know how your analysis is done, or guarantee they won't make a mistake). New 'experimental' features may also be added in these PATCH versions, for testing and feedback.

Larger changes, possibly adding new features, will see the MINOR version number increase. This should be more noticeable to a user... but still not a radical overhaul.

For both PATCH and MINOR version changes, it is always important to check the Changelog associated with each new version to see if you are likely to be affected by any changes, and to check that everything is performing as it should. Sometimes a change may be made under the assumption that it won't affect anyone... but maybe it does affect you. But since I recognize how annoying this would be, such changes should be rare - and I will attempt to avoid them.

MAJOR version changes are reserved for when QuPath changes substantially, or there is some improvement so massive that it needs more attention. This shouldn't happen much.

So when will v1.0.0 be released?

Hopefully one day. However, given how momentous such an occasion would be, it is reserved for the day whenever QuPath's internals are considered suitably finalised that developers can count on (at least the most public parts of) them not changing. Doing so requires knowing how QuPath will be used, and what 'developers' may want to do with it... which is something that is hard to predict, and can only be revealed in time.