I propose embracing a common versioning scheme across all Logging Services projects; log4j, log4cxx, etc. This will make it clear for maintainers which version number to choose for the upcoming release, and ease for users to what to expect from each release. If we have a consensus, we can document this in logging.apache.org.
I propose adhering to the semantic versioning <https://semver.org/> (aka, "semver"), plus some extra constraints for simplification. For one, judging from the content in archive.apache.org/dist/logging, all our recent releases follow the `major.minor.patch` scheme, which is in line with semver. Though I suggest augmenting semver from two aspects. *Limit `patch` pattern* The definition of `patch` is pretty liberal. For instance, this is a valid semver: `1.0.0-beta+exp.sha.5114f85`. Maybe we should limit the `patch` to match the `[0-9]+(-(alpha|beta)[1-9]+)?` That is, only the following will be valid: `1.2.3`, `1.2.3-alpha4`, `1.2.3-beta4`, etc. *Refine semantics* Semver has the following official definition: *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 backward compatible manner* - *PATCH version when you make backward compatible bug fixes* I think we all agree on what warrants a major version bump. The definition of what constitutes an API, etc. are all open to interpretation, but we have a common sense of it in the PMC. We mostly have a problem whether the next release needs a minor or patch version bump. I propose to refine the official semantics as follows: Are we making a release to *only* address a set of particular issues? That is, does the following hold? [next release] = [last release] + [fix1] + [fix2] + ... + [fixN] If so, this needs a patch version bump. Otherwise, this is a minor version bump.
