To Avoid Confusion: Oracle's Confusing New Java Numbering Scheme
twofishy writes "'To avoid the confusion caused by renumbering releases,' Oracle has announced that it is adopting a new numbering scheme for JDK 5.0, JDK 6 and JDK 7. 'The next Limited Update for JDK 7 will be numbered 7u40, and the next 3 CPUs after that will be numbered 7u45, 7u51, and 7u55." The vendor notes that a more elegant solution would require the changing of the version numbering scheme to accommodate different kinds of changes (for example by using 7u44-2 ). However this cannot be implemented outside of a major release, since doing so might break existing code that parses version strings (possibly including the Java auto-update system)"
Here's Oracle's announcement.
An absurd TLA overloading.
Every time they try to standardize version numbers, they make it more confusing. 11G database release 1 was 11.0, but release 2 is 11.2. Where was 11.1? App server 9i was actually an 8.0 base. Most of the time I can't even figure out which product I am actually buying.
Because programs are used to decode/encode the name. It's the same problem with Y2K, user agent strings, and so on. When programs expect data in a certain format, such as two digits for years or a single number after a u in a version string, they don't react well when the format is changed. RTFA.
What a fool believes, he sees, no wise man has the power to reason away.
Wrong. Ubuntu uses YY.MM date-based numbering.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...