Why?
So, their version numbers, unlike everyone else's, are middle-endian? If the rightmost number changes, it's a "must install", but if the middle number changes, you can ignore it?
Does anyone else do version numbering like this?
Version 9 of the Java JDK will adopt a new numbering scheme that tells you which patches you can ignore and which will demand your attention, stat. Oracle describes the new scheme as a “MAJOR.MINOR.SECURITY” regime. Java 9 will therefore be Java 9. If the next update addresses a security issue, it'll be Java 9.0.1. If the …
A quick look at Python 2.7.n releases seem to have the relatively the same goal.
2.5-2.6-2.7 are releases with significant changes. 2.7.1-2.7.8 have been bugfixes, small enhancements & security. Of course, Python 2.7.x is an odd beast, being that the intent is for 2.x to be really superseded by the 3.x series.
Actually, when you think about it a bit, it makes perfect sense.
9.0, 9.1, 9.2, etc are the planned releases with functional changes. The point releases within those are unplanned patches to that release.
Same way it's always been done, it's just that they've pointed out that it's actually the small points that matter, security-wise. If you think about it this has always been true, as the increments within a release will only exist to patch something that was deemed serious enough that it couldn't wait for the next planned release.
Does anyone else do version numbering like this?
Yes, it's also known as semantic versioning. You also see it with lots of open source stuff including Firefox and Chrome
With y as the variable:
x.x.y updates should be drop in for existing systems
x.y.x may include new features but shouldn't break compatibility
y.x.x can be expected to include API changes
In reality you'll often find overlap between the latter two as "minor" changes develop feature creep. Switching to time-based releases is the best antidote there.
You also occasionally see suffixes to the patch version: _1 on MacPorts for the change to a port where nothing upstream has changed. You will also see x.x.x.a stuff à la openssl but that is generally frowned about as semantically vague.
This post has been deleted by its author
Now I need instructions to decode the version number :-)
With this separation of minor and security numbers will they start to issue security updates for minor releases? For example could you get: 9.0.0 --> 9.0.1 --> 9.1.1 and then later both 9.0.2 and 9.1.2? Presumably whatever security issue was found in 9.0.1 wouldn't affect the new code being added in the .1 minor additions.
I hope they don't do this but at the same time if they don't then I can't see any real step forward over what they are doing now. Without security releases for minor updates what they are saying is once in a while the middle number will change and you can skip that release but only for a few days until the end number changes again. Just make the updating process more painless!
Please Oracle, publicly release Java an MSI format, not just a spyware laden EXE (without paying mega$$$ - as one does for breathing in the direction of Oracle).
Save pointless hacking extracting of the MSI from the EXE file you already provide. Or the same MSI file you already provide to purchasers of the Java kits. Overworked admins at medium sized firms everywhere will cry tears of joy in to their stupificant of choice.
Of course, thinking through the design and build of Java so it didn't require constant updating would be a much better thing again.
Pfft.
Run exe, let it extract but don't install it.
Navigate to c:\users\%whatever%\AppData\LocalLow\Sun\Java\jre%version number%\
Copy the msi somewhere else.
Cancel exe.
You're done. It's annoying, yes, but let's not pretend it's some herculean task.
Your suggestion has a flaw. Using leading zeros gives you a hard upper limit. 9999 in your case.
A version number is not an arithmetic value. Version numbers don't typically include leading zero's.
i.e. 1.001 is the same as 1.1, and 1.9 would be followed by 1.10
Using this method, without leading zeros, means you have no practical upper limit to minor revisions, therefore meaning that Oracle could release as many security fixes as required (and as we all know, they will be required!).