Rethinking software versioning

Browsers showed us that you don't have to stick to an ancient and fixed versioning system. In that regard I would like to suggest a new versioning.

1. alpha and beta are wrongly labeled. Why is beta better than alpha? An alpha male is clearly better than a beta male, so we should switch them. First comes the beta version, then the alpha version.
2. the final version should not be named final, but sigma. That means v1.0 is the sigma version.

What do you think? More suggestions?

Attached: 220.jpg (220x106, 4.69K)

>First comes the beta version, then the alpha version.
retard
>the final version should not be named final, but sigma
thats even more stupid
>More suggestions?
yes, kys

Who hurt you?

>tfw still on v1 on my project
>tfw i'm at v1.156.2
FUCK YOU IM NEVER LEAVING V1

I hope you follow semver user :^)

in the age of ci/cd, agile, all that jazz, version numbers are deprecated.
one should refer to versions as per their commit hash.

why yes I'm running version 8d6102a4
wait this was introduced at 4f498b9d
who's the idiot that pushed bf457295?

see? no problem there.

here's the only intelligent way of doing version numbers:
>hash your program
>append UNIX time of the moment the version is approved
>hash again and again append UNIX time

I think both alpha and beta is bad labelling, having versions is complex enough, now adding beta or alpha before a version that is not the same as the stable one, beta 4.1.1 is not the same as stable 4.1.1

4.1.1 would be the major version with a minor update and a patch. Beta should be
5.0.0.23165 So they can have all the shitfest of beta/alpha/dev/canary/whatever updates/patches they want. You know it's the beta/alpha/dev build for version five.

yyyy.mm.dd.patch

>Browsers showed us that you don't have to stick to an ancient and fixed versioning system.
Browser """versions""" are a fucking abomination. You can literally do anything with semver and it's not my fault dumb niggers don't know how to release software

Agree with 1, allows you can start with as much of a low value version as you want
>omega
>gamma
>beta
>alpha
>full release
You can't immediately tell what version is most recent

I don't need to go v2 because I actually did some design and didn't go full agile, unlike Angular, Vue just to name a few
>b-b-b-b-bro we need to bump the major because we have to redo everything and make it non backward compatible because we didn't think enough when we started

>Version 20220323
There. It just werks

libraries (in a broad sense): semver
end programs only interfaced by people: sequential build number (meaning discontinuous as not every build becomes a release)

everything else is unnecessary complication and contrived

These works but not for everyone, these are good for constantly updated software that works more like rolling release and people won't be like "hey, version 23032022 was really nice but 15092023 ruined it for me"
What devs do to tackle this is
>Version 5 Build 23032023/8d6102a4/whatever
Which is not as practical in the end.

:^)

Attached: 1648060372696.jpg (220x106, 4.76K)

You deserve life in prison, pedo scum.

Slightly.... miffed about my post?
Feeling a gently rustle traversing your pantaloons ?
A meager... irratation of the lymbic system?
A chance... flush of blush across the facial ectodermal tissue?

Attached: bnaaag he he.png (300x400, 6.99K)

Are you the one in charge of Kubernetes?

Feeling save behind your screen, huh?

Most importantly, what defines what is a major version?
Some major version changes are dumb.

>Most importantly, what defines what is a major version?
I think complete rewrite

Some baseddevs still think that major should be 1 forever
e.g. Mojang

>Feeling save
lmao learn to type retard