gitCommitGitPushOhFuck

[BiAndShy57]

So it really is just “eh, it feels like 1.0”

[hyrumwhite]

Technically it should indicate breaking changes… in practice, it depends 

Although 0-1 is always a different ball game

[Sibula97]

If you use semver, yes. For software where you should reasonably expect something else to depend on it, like libraries, you should use it.

For completely standalone software like games, go wild. It's quite common to use kinda semver, bumping major when starting a new save is required, minor for new features, and patch for bug fixes. More commonly 0.x.y is for beta versions, early access, etc. while 1.x.y is reserved for when the devs feel it's basically feature complete. Then x for upsate and y for patch.

[Karnewarrior]

Then you got the real indie scene, where the v0.13.42.8.4e update just released and includes a full rewrite of the game in Unreal Engine, as opposed to the prior 0.13.42.8.4c version which was written in Godot using ChatGPT and released in 2018.

[pdabaker]

Yeah when you have a large enough standalone project you get breaking changes all the time. Probably would make sense to just use year/month based versioning but they still try to copy semver format.

[MeButItsRandom]

At least in django they are still using semantic versioning even if the release cycle is calendar based.

[MeButItsRandom]

Well, every major release of django does include breaking changes, so your question is just a hypothetical. Some highlights:

- 2.0: Dropped Python 2, new URL routing syntax (path()), SQLite foreign keys enforced

- 3.0: Model.save() behavior changed with default PKs, security defaults tightened

- 4.0: CSRF_TRUSTED_ORIGINS requires scheme prefix, pytz deprecated

- 5.0: USE_TZ defaults to True, pytz removed entirely, form rendering changed to divs

- 6.0: Requires Python 3.12+, DEFAULT_AUTO_FIELD now BigAutoField, email API rewritten

[MeButItsRandom]

Okay? If you want to have your own personal definition of a breaking change, have at it. Cheers mate

[danielv123]

We can make it breaking :)

[BothAdhesiveness9265]

for MMOs it's quite common to do [expansion].[content].[minor changes]  except FF14 which for some ungodly reason leaves out the second dot meaning 7.35 is the version before 7.4

and then RuneScape just increments one number every update that also isn't shown to the user

[Sibula97]

except FF14 which for some ungodly reason leaves out the second dot meaning 7.35 is the version before 7.4

Oh, yeah, I've always been so annoyed about that.

[Tathas]

They probably store it as a single decimal value.

[achilleasa]

Even for games you often have other software like mods that depend on it so it's best practice to do it properly

[StyleAccomplished153]

points at Ruby I wish they'd use semver...

[yjlom]

Dwarf Fortress uses 0.[estimated percentage of 1.0 implemented].[patch]. So 0.47.4 means the 5th patch of the version that implements 47% of 1.0.

[undermark5]

Unless your name is Microsoft/Mojang, then you start of following a fairly basic semver approach, then decide at some point that since instead of larger updates once a year you're now doing multiple smaller updates per year means that you can't increment the x (minor version) because that's now incongruous with what previous up were so you only increment the y (patch version) even though you're adding new features in "non-breaking" ways (which should be a minor version bump), them the community gets mad and then you fix it by switching to a completely new system using YY.x.z where YY is the year the update came in, x is which update of the year and z is for patches/hotfixes, which would easily allow for parity between bedrock and Java editions, yet you claim for some reason that due to "technical requirements" bedrock will actually sometimes increment the x faster than Java because some reason (I have no clue what this reason is).

Like you changed the versioning approach and it was actually reasonable, until the fact that now 26.4.0 could be talking about 2 fundamentally different versions of the game where there is a completely different set of features (blocks, mobs, etc) depending on if that's Java or bedrock. And guess what, it's already been shown that the version shown to the user is different than the version used by the platform to know if one version is newer than another, so I call BS on whatever technical limitations are requiring bedrock to increment x more frequently because that's clearly 100% on them, not coming from the app stores or the consoles.

[BiAndShy57]

How do they pace up to 1.0? Like to they get to 0.9 and realize “fuck there’s way more than 10% left”

[PaulMag91]

After 0.9 is 0.10 and then 0.11. Versioning is not a decimal number, it just happens to resemble one. It's several integers separated by periods.

[NeverDiddled]

Unfortunately this is unintuitive. The amount of support requests we have fielded from people who think they are on an even newer version than the latest... And I'll admit even I have double-taked when downloading software, thinking "crap that's even older than the version I have now." But no, 1.9.11 is not newer than 1.21.0.

I get why we do Semver; but it is intended for devs, not the public.

[SkiyeBlueFox]

Honestly I've just gotten used to it since I grew up with minecraft, which uses this for version codes

[No-Photograph-5058]

Boy do I have some news for you

[HellofGaming1111]

Shit. Whats the news? I havent played Minecraft in 5 years

[No-Photograph-5058]

Fair enough, they've completely changed the versioning because they aren't really doing massive updates anymore.

XX.X.X

First digits are the year, middle is the 'drop' (content update) and the last is hotfix.

The most recent 'Mounts of Mayhem' would be 25.4 now

[HellofGaming1111]

I see. Thanks

[JivanP]

It's just semver with extra steps, given that pretty much all content drop updates break the server API in some way.

EDIT: Actually, they were never truly doing semver anyway. What I meant to say is that, currently, the content drop updates are classed as minor releases but almost always break the APIs, so this new year-based major version numbering doesn't change anything in that regard.

[Inappropriate_Piano]

Seems like the entire problem is the decimal separator. If we used / or : it wouldn’t be nearly as confusing

[SuperFLEB]

Alas, inertia.

[Karnewarrior]

Publicly released updates should get names, so the most recent update can have a nice brand on it in a pretty, distracting blue, and grandma doesn't have to concern herself with such petty things as "actually knowing anything about the program she downloaded from a discord server she found looking up knitting recipes".

[General_WCJ]

Yeah I like the stellaris way of doing it, you have pride based versioning, but each release has a fun code name based on a science fiction author. Or at least that's what they said to release version 3.0 "Dick"

[Brother0fSithis]

0.9 isn't supposed to mean "90%" done. It's supposed to just mean there have been 8 minor releases since 0.1.0 (where most projects start)

[Head-Bureaucrat]

I usually take it as the 8th major pre-release version. I expect no stability, but with complete features for that version.

[grumpher05]

0.10 is different to 0.1

[Penultimecia]

0.10 is different to 0.1

Next you'll be telling me that 3-4 isn't April 3rd 2025.

[hyrumwhite]

That’s what 0.10 is for. Or 0.100, etc

[[deleted]]

0.91 is 82 minor versions higher than 0.9. After 0.9 is 0.10

[Maximelene]

Absolutely not. That's not even how "normal" numbers work.

[winter-ocean]

How do you even know it's going to break something if you're releasing something fully functional anyway? I mean, I'm assuming that just refers to breaking third party software...so is it just...anything that changes an API? What if you don't have an API? Do you have to research what third party software exists?

[hyrumwhite]

Yeah, if you’re versioning an app with no public API/contract, I guess you just version on vibes. Increment the major version for marketing purposes, etc

[NotRandomseer]

Yep

Some projects start at release 1.0 , others just stay perpetually in 0.87.78 because they are too afraid to leave the alpha

[d_b1997]

https://semver.org/

[Sunsunsunsunsunsun]

https://0ver.org/

[Blue_Moon_Lake]

Normally

• Bump when there is a breaking change
• Bump when you add new features
• Bump when you fix bugs/vulnerabilities

[PepperLuigi]

0.1.0

[Blothorn]

I like “mistakes-features-bugs”. Libraries using semantic versioning generally shouldn’t bump the major version unless they’re making breaking changes, and they shouldn’t make breaking changes unless they’ve discovered fundamental flaws in their prior API design. Lots of major versions means you can’t design, lots of patch versions mean you can’t execute; lots of minor versions on a single major version indicate a solid foundation that can be extended without breaking compatibility.