No mention of server push, so I assume it's not supported?
Reading the page it seems like it is still in quite an early state, I expect they have higher priorities.
Apache 2.4.17 with HTTP/2 support
11–20 of 29 posts
Re: Apache 2.4.17 with HTTP/2 support
#12They added a significant new protocol in a minor upgrade. Is that right?
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 ru…
They don't use semver, and their versioning scheme precedes semver.
Re: Apache 2.4.17 with HTTP/2 support
#13They added a significant new protocol in a minor upgrade. Is that right?
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 ru…
In your example MAJOR.MINOR.PATCH they actually only increased PATCH, Apache 2.4.0 was released in early 2012.
Re: Apache 2.4.17 with HTTP/2 support
#14They added a significant new protocol in a minor upgrade. Is that right?
A better title would probably be: with OPTIONAL http2 support.
Re: Apache 2.4.17 with HTTP/2 support
#15Earlier quoted context omitted.
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 ru…
In your example MAJOR.MINOR.PATCH they actually only increased PATCH, Apache 2.4.0 was released in early 2012.
Ah, I was assuming the mention of "minor" in the post I replied to was referring to minor in the semver sense, without actually checking. My bad.
Re: Apache 2.4.17 with HTTP/2 support
#16They added a significant new protocol in a minor upgrade. Is that right?
It's an optional module rather than changing the core logic (as 2.2->2.4 did), so in that regard it makes sense to only up the minor version number.
Re: Apache 2.4.17 with HTTP/2 support
#17They added a significant new protocol in a minor upgrade. Is that right?
why wouldn't it be right? Not everyone uses semver, and apache project version #'s precedes semver by a long while.
Re: Apache 2.4.17 with HTTP/2 support
#18No mention of server push, so I assume it's not supported?
How would server push from a web server work?
Re: Apache 2.4.17 with HTTP/2 support
#19They added a significant new protocol in a minor upgrade. Is that right?
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 ru…
"backwards compatible bug fixes" don't exist: fixing a bug changes the program's behavior.
Re: Apache 2.4.17 with HTTP/2 support
#20Earlier quoted context omitted.
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 ru…
"backwards compatible bug fixes" don't exist: fixing a bug changes the program's behavior.
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.