4 ms·

> To make it clear that these are time-based releases, and to make it easy to figure out the release date of any particular release, the version strings of feat

> To make it clear that these are time-based releases, and to make it easy to figure out the release date of any particular release, the version strings of feature releases will be of the form $YEAR.$MONTH. Thus next year’s March release will be 18.3, and the September long-term support release will be 18.9. Shouldn't those version numbers be 2018.3 and 2018.9? Have we learned nothing from the Y2K bug?

flukus 9y ago
I'd be more worried about 0 padding the month, imagine the breakage an october release could cause.
swsieber 9y ago
I don't really think that applies? If anything, you know that you can add 2000 to the version version number to get the year.month... if we're to the point where that rolls over, I think we have much bigger problems.
fauigerzigerk 9y ago
Imagine the shock when our descendents wake up on Jan 1 2118 and all their systems are accidentially running on a 100 year old JVM :)
- greydius 9y ago
  I just had the horrible realization that java will still exist in 2118.
  - goatlover 9y ago
    They'll be running the JVM in a Docker container in Linux written in JS in the browser compiled to web assembly running on a Rust WebOS. But it will be okay, because it the hardware will be a 1024 core quantum processor.
- maxxxxx 9y ago
  You think that's funny but there is a good chance this will happen.
organsnyder 9y ago
Only if the first number is constrained to two digits. The release from March of 2100 would be 100.3, which would work just fine.
- maxxxxx 9y ago
  It will mess up sorting. I agree with the suggestion. There really is no good reason why they wouldn't use yyyy.
  - theandrewbailey 9y ago
    How will it mess up sorting? So long as each release has a number greater than the last, they can be sorted properly. Don't ASCII sort. https://blog.codinghorror.com/sorting-for-humans-natural-sort-order/ https://blog.codinghorror.com/sorting-for-humans-natural-sor...
    - maxxxxx 9y ago
      Sure you can be careful. But why not add the 2 characters and be sure?

flukus 9y ago

I'd be more worried about 0 padding the month, imagine the breakage an october release could cause.

swsieber 9y ago

I don't really think that applies? If anything, you know that you can add 2000 to the version version number to get the year.month... if we're to the point where that rolls over, I think we have much bigger problems.

fauigerzigerk 9y ago

Imagine the shock when our descendents wake up on Jan 1 2118 and all their systems are accidentially running on a 100 year old JVM :)

greydius 9y ago
I just had the horrible realization that java will still exist in 2118.
- goatlover 9y ago
  They'll be running the JVM in a Docker container in Linux written in JS in the browser compiled to web assembly running on a Rust WebOS. But it will be okay, because it the hardware will be a 1024 core quantum processor.
maxxxxx 9y ago
You think that's funny but there is a good chance this will happen.

organsnyder 9y ago

Only if the first number is constrained to two digits. The release from March of 2100 would be 100.3, which would work just fine.

maxxxxx 9y ago
It will mess up sorting. I agree with the suggestion. There really is no good reason why they wouldn't use yyyy.
- theandrewbailey 9y ago
  How will it mess up sorting? So long as each release has a number greater than the last, they can be sorted properly. Don't ASCII sort. https://blog.codinghorror.com/sorting-for-humans-natural-sort-order/ https://blog.codinghorror.com/sorting-for-humans-natural-sor...
  - maxxxxx 9y ago
    Sure you can be careful. But why not add the 2 characters and be sure?