Man i think debian would go 14.0 before that
edit:typos
Man i think debian would go 14.0 before that
edit:typos
Is 1312 the new cool number? I thought we were still at 67?
1312 has been the cool number for as long as it has stood for ACAB.
I had never heard of it before... But then I'm not a native speaker so real life people never use it.
You see ACAB in graffiti, now and then. Tha's it.
For a long time I thought AcaB meant "ACAdémie de la Bière.
I still feel dumb to this day.
And I'm about to break
Am I the only one that is annoyed with version numbering in which 13.12 comes after 13.4?
It creates a numerically out of order version increment that bothers me to a degree that it shouldn't.
13.04 and 13.12 would really make much more sense. If you need more than 100 versions, well, you probably should have hit a major release cycle or started with %03d format next time and just pad out x.99... until you go to x+1.
Version "numbers" are actually period seprated lists of integers.
Equally valid could be (13(12(0))).
All i ask, as a humble admin please dont make breaking changes in the minor or patch colums.
Nah. It's not meant to be decimal points. It's separation between numbers
%YYYY.MM format is a separation between numbers. But still increments in a numerically ordered way. I'm not saying I don't understand version numbers. I'm saying padding zeros makes it easier to read.
It doesn't really matter with a release cycle that has less than 10 version increments. Which is fine if you're only ever gonna hit 13.9 in very rare cases.
But if you constantly have x.yy version numbers. You should probably start with some zero padding. All I'm saying.
13.1
13.11
13.12
13.13
13.2
13.3
Is ugly and annoys me.
Have you seen formats that use unpadded seconds, minutes and hours? 11:4:7 is just beautiful time formatting π₯Ή /s
But they're integers not strings, so are sorted differently...
I'm sorry if your head treats them as strings but that's like, a you problem, man...
Welcome to the thread. It's something that annoys me in which I asked if it annoyed anyone else. I'm not sure why you're trying to explain away my annoyance with information I already know.
Also, filenames are quite literally strings. That's how the image binaries will be sorted. As filenames.
release_1.1.bin
release_1.10.bin
release_1.2.bin
And yes I'm aware of sort -V. I can still have an OCD annoyance with it. I swear to God if someone replies again telling me why I shouldn't be annoyed.
At this point I'm more annoyed with replies than I was version numbers.
Yeah, you're right - I was thinking of them in isolation like a silly billy
All good. I'm in a piss poor mood too and just rambling.
Its like that thing though, where you introduce someone to a new pet peeve they've never noticed - so thanks, I guess...
ls | sort -V now that I've cursed you.
But I'm running out of mental storage space for bash commands. I wish I could clear some space.
Make a bash alias once, get the correct behavior forever.
What's worse is making a bunch of bash aliases that are easier to remember and then you hit an environment you can't use your bashrc in for whatever reason. Then you have no idea how to actually do anything.
I try to only use aliases for things that I repeat often but are only going to be used in my specific environment.
Unless you mean
alias ls="ls | sort -V"
Which would be really awful to do for obvious reasons.
That example is indeed what I meant. What's awful about it?
edit: I use a customized ls alias. Most of the time it's fine, and when I occasionally need the default output, I can type /bin/ls, no new alias to memorize. The history command suggests I do this pretty infrequently, though ymmv.
ls doesn't have the version sort option so since you're aliasing a piped command to sort you'd be passing any additional commands to sort
So
ls -r
Would actually be
/bin/ls | /bin/sort -V -r
You could overcome this with xargs but it's just definitely a bad idea in general to alias a standard command piped into another command. Will cause headaches.
Where as something like
ls="/bin/ls -r"
Just defaults ls to a reverse sort and you can still safely add additional args.
for f in $(find /); do mv $f $(echo $f | sed 's/.([0-9])./.0\1./'; done
ftfy
edit: dont actually run that
This has always bugged me, too! I understand it. It isn't inaccurate. I've probably done it myself in the past. But the way it looks bugs me.
i get that and it was my initial reaction too, but doing it differently would force a major update after versipn x.9 which makes no sense either
all 42 comments