Slackware 14.2 to Slackware 19, numbering by year!
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
If I were to play silly versioning games with a distro of my own, it would be timed to be one version higher than CentOS, release a couple months before CentOS, and use most-stable package releases slightly newer than CentOS.
It would be a datacenter-oriented Slackware, so it would pretty much depend on peeling users away from CentOS/Suse to have any kind of following.
Actually, as a user I prefer very simple, sensible, progressive numbering, i.e.: 1, 2, 3, 4, 5, etc. Most importantly it indicates a stable version and enables to track releases historically. Ideally point releases should refer to the system which has received some updates, which did not had much impact on existing system "structure". Trouble is that this method does not go well with marketing at all and if you want to be popular it's not a great idea to use it. However, I would like this method even more now, that everyone seems to use random version numbers which are utterly confusing to humans :-)
Then again, I'm not a developer. They might have individual preferences for versioning stuff. Bottom line, as user I simply want to know if the software is stable, and if it's latest.
Last edited by Totoro-kun; 08-19-2019 at 03:55 AM.
For those that don't know, Slackware already played the "increase version numbers to match competition" game back in the 90s.
Quote:
Q: Why the jump from 4 to 7? The following was posted to the Slackware.com Forum by Patrick Volkerding (Slackware Project Lead), at 21:43 10-10-1999.
I've stayed out of this for now, but I do think I should lend a little justification to the version number thing.
First off, I think I forgot to count some time ago. If I'd started on 6.0 and made every release a major version (I think that's how Linux releases are made these days, right? , we would be on Slackware 47 by now. (it would actually be in the 20s somewhere if we'd gone 1, 2, 3...)
I think it's clear that some other distributions inflated their version numbers for marketing purposes, and I've had to field (way too many times) the question "why isn't yours 6.x" or worse "when will you upgrade to Linux 6.0" which really drives home the effectiveness of this simple trick. With the move to glibc and nearly everyone else using 6.x now, it made sense to go to at least 6.0, just to make it clear to people who don't know anything about Linux that Slackware's libraries, compilers, and other stuff are not 3 major versions behind. I thought they'd all be using 7.0 by now, but no matter. We're at least "one better", right?
Sorry if I haven't been enough of a purist about this. I promise I won't inflate the version number again (unless everyone else does again
I think most people realize Linux distro version numbers are unique to that distro and I doubt he has nearly as many questions posed to him as to why Slackware is at 14.x when others are a higher number. So I don't think there's any need to artificially inflate Slackware's version number again, but then it's always up to the BDFL
It's all arbitrary anyway. It's not like the major version numbers have any significant meaning - ie, it's not like 14.0-14.2 all use the same major version of the kernel, glibc, etc. I remember back in the days of Red Hat Linux and decimalled version numbering, the point-releases all had inter-compatible packages with one another as they used the same major version of glibc and (I believe) gcc.
I guess I can see the justification of using point-releases as kind of a loose concept if there haven't been sufficient major changes between releases to justify a major version-bump. But when versions are coming out 3+ years apart as opposed to a maximum of 1 year as was the case in the past, the case for using minor version numbering kind of disappears.
Again, I don't particularly care though, since the version numbers are arbitrary anyway.
RHEL and its derivatives are sort of like that, today. Software that runs on 7.0 is supposed to run on all 7.x releases. Slackware does more or less more or less the same thing, but without bumping version numbers. A stable Slackware release sees upgrades over its supported lifetime similar in scope and degree as a major-version RHEL release. Far fewer packages, though, and sbo packages are seldom upgraded.
RHEL and its derivatives are sort of like that, today. Software that runs on 7.0 is supposed to run on all 7.x releases.
Yeah, but RHEL "point releases" are more like Service Packs, they do NOT upgrade packages, just patch them for security or bugfix reasons.
So any 3rd party application can expect the same type and version of packages in all of the 7.* installations.
And of course the same is true for the corresponding CentOS releases:
they've even stopped versioning the iso's for the point release:
Code:
File:CentOS-7-x86_64-DVD-1810.iso 4481024 KB 11/25/2018 12:00:00 AM
File:CentOS-7-x86_64-Everything-1810.iso 10491904 KB 11/26/2018 12:00:00 AM
File:CentOS-7-x86_64-LiveGNOME-1810.iso 1439744 KB 11/24/2018 12:00:00 AM
File:CentOS-7-x86_64-LiveKDE-1810.iso 1903616 KB 11/24/2018 12:00:00 AM
File:CentOS-7-x86_64-Minimal-1810.iso 940032 KB 11/25/2018 12:00:00 AM
File:CentOS-7-x86_64-NetInstall-1810.iso 519168 KB 11/25/2018 12:00:00 AM
They've got a date (-YYMM, of the source release of RHEL it is based on) but not a 7.x version, just a plain 7
Slackware is not trying to be like other distros. Slackware does not do rolling releases and it is best this way.
Version numbering is not a race. Concrete example: back in 2011, did it mean that Ubuntu 11 was better than Ubuntu 10 or Slackware 13.37? Not at all! So, version numbers are relative. It is just a counting system. And it certainly cannot be used as parameter for comparison across distros because everyone has their own standard.
So, eagerly waiting for Slackware 15. Whenever it will be ready.
Last edited by aragorn2101; 08-26-2019 at 04:32 AM.
Version numbering is not a race. Concrete example: back in 2011, did it mean that Ubuntu 11 was better than Ubuntu 10 or Slackware 13.37? Not at all! So, version numbers are relative. It is just a counting system. And it certainly cannot be used as parameter for comparison across distros because everyone has their own standard.
It's true, but in the "real" world companies and software is now actually racing in a fake race with these version numbers, pretending they are not irrelevant or relative. Among some examples are Apple, Microsoft and Google, but this race also suddently included Firefox which annoyingly started using a new version scheme when Chrome versions turned double digits and Firefox was something like 2.3.14 or whatever. Suddenly every minor bugfix is a minor release and any minor release is a major release. Who can get the highest number the fastest?
It's a rat race and people actually think version numbers matter when comparing different operating systems and software, because the companies pretend it does.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.