Apache version numbering is similar to what the linux kernel used before 2.6.
In a.b.c, odd b indicates the unstable or experimental branch, and even b's are used for major and backwards-compatibility breaking changes.
Backwards-compatibility preserving changed can be introduced in c.
So 2.2 and 2.4 are pretty different versions, while 2.3 and 2.4 are closer except 2.3 is unstable. 2.4.0 is theoretically compatible with 2.4.17, except the latter has a lot more functionality and features.
If all it does is add new functionality, and doesn't modify or break any existing functionality, then that seems to be good software engineering to do in a minor upgrade doesn't it?
Seems valid: MAJOR.MINOR.PATCH, with the minimum changes being increment "patch" for backwards compatible bug fixes, "minor" for new/improved functionality that does not break backwards compatibility, and "major" for any API/feature change that is not backwards compatible. They could of course chosen to increment MAJOR instead, but they don't have to in this case.
(I'm assuming they are following "standard" semver rules here)
Compatibility in this case is referring to published APIs and not changing documented behaviour. There are a large family of changes that are bug fixes that don't change correct use of an API - many security fixes for example.
In a.b.c, odd b indicates the unstable or experimental branch, and even b's are used for major and backwards-compatibility breaking changes. Backwards-compatibility preserving changed can be introduced in c.
So 2.2 and 2.4 are pretty different versions, while 2.3 and 2.4 are closer except 2.3 is unstable. 2.4.0 is theoretically compatible with 2.4.17, except the latter has a lot more functionality and features.