1. 26
  1.  

  2. 3

    This is like 4.0, where it’s a major version change only so that the second number doesn’t get too high, right?

    1. 14

      But I’d like to point out (yet again) that we don’t do feature-based releases, and that “5.0” doesn’t mean anything more than that the 4.x numbers started getting big enough that I ran out of fingers and toes.

      Looks like it, yeah.

      1. 6

        At this point I think it would be more appropiate to just increase major version? Kind of what firefox did back in the day. The separation between minor and major doesn’t exist here and it’s kind of misleading.

        1. 5

          That’s a good point. For some kind of software (e.g. end-user software or software with stable API/ABI) regular versioning, or semantic version don’t make sense. Another idea is to use calendar versioning.

          1. 4

            But then the number would get too high!

            1. 5

              It would be devastating to run out!

              1. 14

                Past 2.147.483.647, it finally starts being a true 64bit operating system.

              2. 1

                It’s not like we’re gonna run out of integers.

                1. 2

                  Every time I hear something like that, I think about the exhaustion of the IPv4 address space. No, we didn’t run out of numbers… just unsigned 32-bit integers.

                  I cautiously agree with your assessment in regard to version numbers; if we did have to migrate to something else, it would be an easy migration to make.

                  1. 2

                    Every time I hear something like that, I think about the exhaustion of the IPv4 address space. No, we didn’t run out of numbers… just unsigned 32-bit integers.

                    Well, there’s also how they get whole blocks of addresses. When I studied networking, I figured we should just give out individual addresses or numbers as they use them. One per server or public-facing node. Instead, they did blocks where one company with lots of money could have an easy, organization scheme (esp hierarchical) using piles of I.P. addresses they might not even use at great expense to the Internet in terms of fair distribution.

                    A single, 64-bit number with a good, routing scheme could’ve gone a long way.

                    1. 3

                      Had the ’net been based on single addresses there would not have been a guarantee of route locality between neighbouring addresses. In the days of yore when memory was expensive and Cisco-memory double-plus-ungood expensive it would have been more or less impossible to implement a scheme like that and still keep the routing infrastructure going. Routing tables were overflowing as it was, even when routing on base of AS instead of on single addresses.

                      1. 1

                        Had the ’net been based on single addresses there would not have been a guarantee of route locality between neighbouring addresses.

                        I think we could build that into the routing protocols. They were already using metadata in the form of the IP addresses themselves and what was in routing protocols. I can’t tell you exactly what it would look like but we did develop similar ideas for domains with DNS.

                        1. 2

                          Of course it could have been built in, that was never the problem. The problem was that the routing tables would have become too big to fit in the relatively small amount of memory available on core routers back then.

                      2. 2

                        Yeah. Oh well. We can try that on the next planet, I guess. That’s not what IPv6 does, and it’s hard to imagine going through another multi-decade migration without a very strong reason.

                      3. 1

                        I was mostly being a smart-ass. I have heard people object to UUIDs as identifiers for some large but not-that-large set of entities, and I always respond “we’re not going to run out of integers, people”.

                  2. 2

                    I don’t like Firefox’s numbering scheme. I can never remember what version of Firefox is meant to be the latest.

                    It would be much better to use dates. Linux 19.3 for the March release, Linux 19.5 for May, etc. It comes out every 2-3 months. Or perhaps just 19.1 for the first release of 2019, 19.2 for the second, etc.

                    1. 1

                      Y2.1K

                      1. 1

                        Yes, I agree just a single number probably is not that much better (although I think it’s better than what Linux does now where minor and major means exactly the same).

                        I think your CalVer idea is better.

                  3. 6

                    This is always the case with the linux kernel.