Versions are denoted using a standard triplet of integers: MAJOR.MINOR.PATCH. The basic intent is that MAJOR versions are incompatible, large-scale upgrades of the API. MINOR versions retain source and binary compatibility with older minor versions, and changes in the PATCH level are perfectly compatible, forwards and backwards.Novelang is not unlike a code library: you provide sources (documents) and I deliver software interpreting it. Specification of the software may change, including breaking backward compatibility (that I'll try to avoid at least because of my own Novelang documents). But wait, there is more. Since the Book feature is checked in, Novelang becomes a platform running arbitrary Java code that foreign developers may plug in. Same compatibility problems occur on a different dimension. How to reflect changes on those two dimensions? Should I mix them just telling if backward compatibility is maintained for both, as users are just users, whether they are developers or text writers? I don't need to find an answer by now but the solution may not be obvious so I have to start thinking on it by now. Do you know about other tools having the same problem?
Now I'm working hard for a first public release. I don't expect many people to use Novelang because it lacks many features and is still subject to change, but "think big, start small". Here comes the question of versioning. APR versioningprovides a good conceptual framework for thinking about about to set version numbers: