Hacker News Reader

Comment by igravious | Hacker News Reader

Possibly because lots of software out there expects n.n(n) and not 20nn.n(n) ?

Wasn’t part of the reason behind the 2.6->3.0 change to help shatter some of those preconceived notions about version numbers?

Providing each year is a higher number than last year, why does it make it incompatible?

We had a turn of the century during Linux's life span, 1999-2000, which coincidentally was going to be a problem because so many computer systems used a two digit year.

So we have 80 years to solve the issue of supporting the version going from 99.X to 2100.1 :)

Now double that estimate, add some padding, and I am looking forward to the release of 2230.1

Throw in Windows XP becoming sentient and recreating the Windows Subsystem for Linux equivalent for Linux itself.

Good god man. What dark beasts lie in you.

I find it ridiculous people still cling to XP and IE, just wanted to poke fun. :)

spoken like a true project manager

But a 4 digit year as a version is ok, right?

It just breaks existing regexes. When the kernel switched from 2.6.x.y to 3.x.y, it broke a lot of shoddy scripts that expected the version number to match e.g.

  /^\d\.\d\.\d\.\d$/

Are kernel maintainers responsible for shoddy scripts though?

Linus has the (imho: valid) expectation that kernel changes should not break userspace (for detailed explanation see: https://unix.stackexchange.com/a/235532). Even if the version numbering is not an explicit API like say, file system drivers, the versioning of the kernel is an implicit guarantee that the kernel has made to userspace.

At some point, I think so.

It's similar to a discussion I saw on here about Chrome adding a feature that you could use with a certain html attribute iirc, ie <div newattribute> or something.

Supposedly, nobody should have an attribute called 'newattribute' anywhere in their application, but that doesn't mean that there are is a non-zero amount of applications out there that do.

The problem is not so much that you can point and laugh at the crappy regexes, or crappy html-devs, the problem is that some scripts on some server, or some sites somewhere don't really have a maintainer anymore.

For tiny, tiny projects, you don't really have to take this into account, but if you're Chrome or the Linux kernel, you definitely should take it into account.

19.1, 20.1

We can safely assume that for the next 80 or so years that the year will begin '20'.

That leaves 80+ years to patch the software that expects a certain version number format. Plenty of time.

Plenty of time, I suppose. But if history is anything to go by, you can be sure we'll wait until the last minute to start fixing old software.

Yes I was wondering whether to add a /s tag to that last sentence.

Hopefully they'll future proof it, or they'll be cursing us come 9999.

Who will stop us going from 99.nn to 100.nn?

As I said we have 80 years to patch the software.

The scheme was suggested to avoid a 20nn.n scheme that the parent identified.

Theres nothing to stop us from going from 99.nn to 100.nn and I wont be there to stop it. I'll remind my kids to point it out though :)

Reply on news.ycombinator.com