@nikitonsky isn't this how it already works for most things
@hazelnot @nikitonsky I honestly have no idea how versioning works and just assumed this is how it works lmfao
@ivy @nikitonsky @hazelnot it shouldn't be how semantic versioning is done but a lot of developers just do whatever the fuck they want lol
i also may have been guilty of doing this in the past :3
@nikitonsky @ivy @hazelnot in theory it should be major.minor.patch where major is only incremented for breaking changes
@lily@ice.floofy.city @nikitonsky@mastodon.online @ivy@cutie.city @hazelnot@sunbeam.city woah I learned something today
@lily @nikitonsky @hazelnot fair, but what happens if you get to like 1.9.9 and your next update is also not breaking so then it's like 1.99.9 or like what if everything is always backwards compatible
@ivy @nikitonsky @hazelnot after 1.9.9 the next update would be 1.10.0
@lily @nikitonsky @hazelnot ooh ok interesting
@lily @ivy @nikitonsky @hazelnot ohhhhhhh. thanks
@lily @ivy @nikitonsky I used to think that after 1.9 comes 2.0 and was confused when Minecraft 1.10 came out
@lily @ivy @nikitonsky I was already legally an adult at that time btw
@hazelnot @nikitonsky @ivy the way minecraft does versioning is really funny. i assume it doesn't follow semantic versioning but we look at it that way that would mean that there were no breaking changes between 1.0 and 1.21 or whatever is the latest
@lily @nikitonsky @ivy to be fair you can just, load a map from Minecraft 1.2 and it will work
Not seamlessly, the new chunks are gonna be hella different, but it will work. And if you factor in converting the file it will apparently work all the way back to Infdev-20100327
So I think it would be like, 2.something, cause the previous map format was from the beta which wouldn't count since they reset versioning between the development stages
@hipsterelectron I'm not joking I'm just dumb
@ivy i deleted bc i didn't feel like i fully understood whether @lily was joking and/or whether they were talking about an intricacy i didn't understand sorry!! i rly wish the . separator wasn't used bc it reads like a decimal to me and in fact the three columns are completely distinct nonnegative integers. they were obv correct that if you make a new minor (middle) release, that that resets the patch (right) counter to 0 (and major/left does the same to minor and patch)
@hipsterelectron @ivy the reason i said 1.10.0 and not 1.9.10 is because she asked the next update, not the next patch
@ivy @lily this gets much more tricky if you are trying to parse version strings as constraints as opposed to concrete strings. i have tried to rewrite the version parsing in @spack literally 5 times so far and i keep throwing it away—spack will parse any version string and has a hook method to parse horrific stuff like openssl versions. it's ludicrously interesting but fundamentally at this point i think we should not be stringly typing versions, either concrete or constraint
@hipsterelectron @ivy@cutie.city @lily @spack c'mon Danny, it's one regex, what could it cost? 2 pegged cores?
@arichtman @ivy @lily noooooo don't make me think about parallel compiling regex that's the one thing that was safely serial!!! spack's code is actually very straightforward for parsing it's actually calculating whether something like @3:4
contains the concrete version @4.1
and propagating inclusivity of range endpoints where everything gets hairy and awful. other package managers have it easier bc they can restrict what packages can declare but spack supports literally every codebase including non-semver ones so it needs to be completely general
@hazelnot Yes. The most devastating breaking changes are typically in a "patch" release.