It does not really matter if it is a library or larger application. A semantic versioning scheme (like semver) works perfectly well for large application. It can even be used for a collection of applications bundled into a platform, but here it becomes quite difficult to tackle.
The main question is if you are going down the route of supported depreciation in one release and only removal of it in the next major. Having deprecated, but supported functionality, can take quite a bit of effort. When you are going to make changes to your persisted data model deprecating can often become impossible. If that happens you cannot even do a minor version with deprecated functionality, and you instantly jump to a next major. This is the part where large application usually have problems. You go from 3.0.0 to 3.0.1 to 4.0.0 because you cannot provide backwards compatibility. If you often have breaking changes sticking to semver adds little value.
Having said that. I much more prefer that construction because it communicates more clearly to developers that there is going to be breaking changes. YYYY.N scheme tells me nothing as a developer, and nothing as an admin.
So the question is, what do you want to communicate with the version? If you want to do 6 feature releases (which might or might not be breaking), and every 6th release will be longer supported with patches; and you do not want to version patch releases. Then X.Y is a suitable scheme where Y=0 is the longer supported one. X would be just a number. The problem is when X is the year, then Y quickly is associated with a month. So newer longer supported releases will be released in January? I always have to look up which Ubuntu version is an LTS, which annoys me.
So what if Discourse simply continues with the current major. The next longer supported version is called 4.0; and then we get 4.1 to 4.5 as feature releases; followed by 5.0 which is the newest longer supported one.
Then you also don’t have that awkward moment where a release is delayed because of a major issue.
You could optionally add a “patch” number if you plan to explicitly release patches (instead of having rolling patch releases). “But then you have x.y.z which is semver”. Well no, it looks like semver, but it is not. Every new “minor” release can be breaking. So I suggest to just stick to X.Y as version scheme with Y=0 → LTS
Version string aside. I do like the new release plan.