Hacker News Reader

Comment by doodpants | Hacker News Reader

> 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?

View on HN

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 :)

You think that's funny but there is a good chance this will happen.

I just had the horrible realization that java will still exist in 2118.

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.

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.

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.

It will mess up sorting. I agree with the suggestion. There really is no good reason why they wouldn't use yyyy.

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-sor...

Sure you can be careful. But why not add the 2 characters and be sure?

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

Reply on news.ycombinator.com