The way releases used to work for the past ten years or so was that after a major release, every couple of months there would be a bugfix/security patch, and every six months (for a year or more) there would be a feature release (that used to be called "limited update") with major new features (new GCs, new monitoring mechanisms etc.) but without spec changes to the language and libraries. This meant that all the changes that required changing the spec had to wait for the major release. This had several bad implications. Most if not all of the spec changes were no more disruptive than the changes in the feature releases, but they had to wait for the next major release -- a lot of changes delivered at once created an overall fairly large disruption. Also the major release had to wait for the large features, and people couldn't enjoy smaller ones. Finally, people wanted to get their changes into the next major release so they wouldn't have to wait another three years or more, so features were merged before they were fully tested, which meant that the .0 major release was noticeably less stable.
So, to make the upgrade process easier and cheaper, Java got rid of the major releases, allowed making spec changes in the feature releases, and, with the major releases gone, every feature release gets a new integer name. The result is a much more gradual process. Every feature release is about as big and only slightly more disruptive than the old feature releases. The releases are now much more stable because features are merged only when they're mature enough; there's no rush because if you miss a release, there's another in six months.
The ecosystem will take some years to adjust, but those who've made the transition to running in production on the current release (many still can't, as some tools haven't yet adjusted) report a smooth process.