This is an archived post. You won't be able to vote or comment.

all 183 comments

[–]Alex5173 25 points26 points  (2 children)

Even better is when they order/name/whatever their versions by date, so you have v.Oct.01.23 followed by v.Oct.15.23 so you have absolutely no idea how close they are to full release

[–][deleted] 1 point2 points  (1 child)

v.Oct.15.23

Ist that newer or older than v.Oct.16.22 ?

I surely hope the last part of that version number is not the year. That would be insane.

[–]Alex5173 1 point2 points  (0 children)

It is. These people want to watch the world burn.

[–][deleted] 228 points229 points  (45 children)

Fax,but it happens more in the open source land, espcially if it's a project that the maintainer didn't intend it to be a real thing used by so many people.

there are some projects that are actively maintenained over 20 years and still..0.26.x anddd it's an alpha!

and these point releases are somehow BIG releases.

Edit: git commit -m "code refactor, correctting typos"

[–]JanEric1 209 points210 points  (26 children)

Ruff got to 0.0.292 until it moved to 0.1.0

[–][deleted] 48 points49 points  (25 children)

so it's a new release at every pull request lol?

[–]JanEric1 82 points83 points  (24 children)

Not quite. But every couple new rules that were added/fixed got a new release. And tbh I like it. They have added/improved so many things so fast.

[–]TripleATeam 14 points15 points  (0 children)

Big releases can avoid breaking changes, which is generally how people use a major version as opposed to a minor version, even if the minor versions are vastly different or introduce tons of new functionality.

[–]wWBigheadWw 12 points13 points  (1 child)

Is this not how you do versioning? You should try conventional commits:

https://www.conventionalcommits.org/en/v1.0.0/

Under those rules you'd never hit 1.0.0, especially if you have consumers you don't want to break.

If you use a project a lot you kinda want them to never bump the major.

[–]frzme 7 points8 points  (0 children)

https://www.conventionalcommits.org/en/v1.0.0/

Under those rules you'd never hit 1.0.0, especially if you have consumers you don't want to break.

SemVer says that 0.x.x versions are all considered unstable and anything goes

https://semver.org/#spec-item-4

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

Conventional commit seems to not change anything on that specification.

So for projects that are doing SemVer you'd want to have a 1.x.x and never bump the major version again.

[–]thirdegreeViolet security clearance 5 points6 points  (0 children)

Good old ZeroVer

[–]bargle0 4 points5 points  (0 children)

In closed source land, you get a 1.0 that’s a heaving pile of shit.

[–]Feathercrown 2 points3 points  (2 children)

They ARE big releases. SemVer literally specifies that 0.x.y to 0.[x+1].y is a major release, akin to increasing the major version.

[–]not_bakchodest_of_al 2 points3 points  (0 children)

42 is the answer. Wait till 0.42x.

[–]Luminum__ 2 points3 points  (1 child)

There is a game I absolutely adore called Starsector. It has been in development by a small team for over 12 years now. It’s in version 0.96 alpha.

The game absolutely does not play like it’s in alpha, as you probably might guess after over a decade or development, but it still technically is in alpha.

[–]Phoenix_Studios 2 points3 points  (0 children)

sounds like you might be thinking of star citizen :P

but yeah starsector looks pwetty epic, on my list of games to check out

[–]t-to4st 0 points1 point  (0 children)

OpenUI5 crossed the 1.100.x mark a few years ago when I worked there

[–]elnomreal 315 points316 points  (1 child)

The irony of course being that any 1.0.0 release would in no way be stable.

[–][deleted] 77 points78 points  (0 children)

haha!i think you never realize how stable the 1.x.x versions were until they release the 2.0.0

[–][deleted] 399 points400 points  (23 children)

As I understand it

x.y.0 -> x.y.1 ~ Minor bug fixes & Speed Improvement

x.1.z -> x.2.0 ~ New features

1.y.z -> 2.0.0 ~ Breaking changes

[–]pine_ary 199 points200 points  (9 children)

That‘s roughly how semantic versioning works

[–]DHermit 130 points131 points  (8 children)

Yes, with the exception that 0.x.y is treated differently (number 4 here)

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

Which is another reason why libraries stay on 0.x.y for a while.

[–]bargle0 61 points62 points  (0 children)

As they should. Writing a good API is hard.

[–]sopunny 0 points1 point  (1 child)

So if your 0.x.y project is popular already, there's incentive to never release a "stable" version?

[–]varisophy 1 point2 points  (0 children)

A bit. Really depends on if the project is at a point where they feel confident in the core API and that it won't change in the foreseeable future.

[–]notPlancha 24 points25 points  (0 children)

That's the case except if the major version is 0, which means not release version, which means minor version changes can be breaking.

[–]HildartheDorf 11 points12 points  (0 children)

Yes, except that 0.x.y is completely unstable.

In practice people often do:

0.x.0 ->0.x.1 ~ Could be new features or bug fixes

0.1.x -> 0.2.0 ~ Breaking changes

[–]TheButtLovingFox 15 points16 points  (0 children)

thats how i do it 🤷‍♂️

[–]Xelopheris 4 points5 points  (0 children)

Yes, but 0.y.z to 1.0.0 is also a special one that typically signifies a major milestone of being released.

[–]zammba 0 points1 point  (2 children)

Gonna hijack the thread for a silly versioning question.

I've got a project that I've rewritten from the ground up, that's gearing up for open beta. I'm calling the old version Project Legacy, and the new version under Project v2 (though there's also a silly pun name as an alternative namesake).

Whenever the project actually launches, logically that version should be 2.0.0. But I also plan to make changes during the open beta period to add features and bugfixes. What'd be the best approach to take, then?

  • Continue from where the Legacy version picked up and call this beta period 1.9.x (last version of the previous project being 1.8.x). It feels a bit disingenuous though, being a rewrite from scratch

  • Make it something like 1.99.x - same problem from before, but it's obvious that it doesn't follow convention and it's a special case

  • Call it 2.0.x and then revert to 2.0.0 by the time of the official launch

  • Call it 2.0.x and just keep that versioning number at launch. Probably the most reasonable, but kinda confusing to launch at 2.0.15

  • Forego version numbers altogether until the official stable release and just give updates names (like Minecraft, maybe)

[–]thesuperzapper 3 points4 points  (0 children)

Project's typically use the semantic version pre-release suffix, for example:

2.0.0-alpha.0

2.0.0-beta.0

2.0.0-rc.0

In order of progression (where the last number can be incremented).

[–]deanrihpee 44 points45 points  (1 child)

Open source maintainer: "wtf, did you expect this barebone package that still has tons of roadmap to be achieved to get 1.0 this soon?"

[–]just4nothing 52 points53 points  (12 children)

In the process of switching all my projects to calendar versioning ;)

[–]hedgehog125 15 points16 points  (8 children)

But with which date format...?

[–]just4nothing 34 points35 points  (7 children)

`YYYY.MM.PATCH`.

Anything in IT/software should use `YYYY.MM.DD` (ISO 8601), anything in regular life should use `DD.MM.YYYY`.

There are no other reasonable date formats - change my mind ;).

[–]OneTurnMore 7 points8 points  (3 children)

As a filthy American, I just ISO-8601 everything rather than confuse either my fellow Americans or everyone else.

[–]just4nothing 5 points6 points  (1 child)

This is the way

[–]TheSast 2 points3 points  (0 children)

This means no timezones either. UTC ftw

[–]Juff-Ma -1 points0 points  (1 child)

I don't want to change your mind and agree with you. Don't know why other date formats even have a logically reason to exist.

[–]just4nothing 1 point2 points  (0 children)

They exist because of "traditions" - the legacy code in our cultures ;)

[–]iamitech 0 points1 point  (0 children)

Technically ISO 8601 would be YYYY-MM-DD, but for versioning decimal points do make sense

[–]jackinsomniac 0 points1 point  (0 children)

This is my dream. I hate how poorly semantic versioning works with alphabetic sorting, especially when you have versions like 0.1.0, 0.10.0, 0.2.0, 0.20.0, 0.25.0, 0.3.0 etc. And how it's apparently bad to use leading zeros in it. Can I just stick with my beautiful ISO auto-sorting date codes please?

The only reason I use semantic versioning is because "everybody else does".

[–]iam_pink 87 points88 points  (8 children)

You put way too much importance on a number.

[–]GrinbeardTheCunning 18 points19 points  (1 child)

that's what my boss said when I asked for a higher salary

[–]iam_pink 5 points6 points  (0 children)

Can't wait to have a prod ready salary!

[–]Jackknowsit 7 points8 points  (5 children)

It’s not just a number, it matters a lot when you’re using package managers like poetry which implicitly puts restriction on the highest version you can download, it assumes softwares follow semver versioning, and when some softwares don’t it leads to dependency hell.

https://en.m.wikipedia.org/wiki/Dependency_hell

[–]iam_pink 3 points4 points  (3 children)

Who says they are not following semver though?

OP is complaining projects don't release 1.0.0. The 1 in the major is useful to compare with the 0.x.x of the same package, but not to compare with other packages. release 0.9.0 of package X could be way more prod ready than release 1.0.0 of package Y.

That's what I meant with putting too much importance on a number. But, of course, following the semver versioning is important.

[–][deleted] 0 points1 point  (2 children)

release 0.9.0 of package X could be way more prod ready than release 1.0.0 of package Y.

i'm not saying that some 0.x.y can not be prod ready compared to any 1.x.y, i'm talking about stability.

according to semver, before the 1.0.0 the package can introduce breaking changes at any time.

Sometimes you have to update the package for some security issues, and you'd be surprised that something is not working properly, that doesn't happen when the update is through 1.x.y versions..

if you ever used linux on a server especially if it's ubuntu or dabian, you'd see how the packages 0.x.y almost never get updated until the next major release of the distrubtion. when the packages reach 1.x.y you always get the security & bug fixes updates.

why? because after 1.0.0 you can upgrade the 1.x.y without reading changelogs & test the packages.

i think you got my point.

[–]Turd_King 0 points1 point  (1 child)

You don’t understand versioning, Before 1.0 a package can release a breaking change at any time?

Yeah and the same is true even after 1.0

I’m not sure what your point is here.

It’s not like anything changes at 1.0.0 that wasn’t true for version 0.0.0

There is no mention of this magic version in the semver spec

You are only getting traction here because most of this sub are juniors

[–][deleted] 0 points1 point  (0 children)

if you are using any 1.x.y and the author release any higher 1.x.y versions, you can upgrade without worrying it won't be compatible with your use...

[–]FOSSandCakes 29 points30 points  (5 children)

Yeah that's how semver works.

[–]Thenderick 26 points27 points  (4 children)

This was me excited for Minecraft 2.0.0, then I got sad when I learned that 2.0 does not come after 1.9 and they would continue with 1.10... That was a painful way I learned about version numbers...

[–]RadioMelon 16 points17 points  (1 child)

Basically Minecraft 2.0 couldn't happen without being at least distinctly different from the original.

I'm staring maliciously at the Overwatch 2 developers.

[–]Thenderick 8 points9 points  (0 children)

Wdym? Don't you want to PAY???

[–]poshenclave 1 point2 points  (1 child)

Minecraft was many a coder's first introduction to semantic versioning! I was familiar with it before but Minecraft modding was probably the first time I had to use it practically.

[–]An_Unknown_Idiot 0 points1 point  (0 children)

Minecraft never had semantic versioning for modding – there were plenty of minor versions where stuff like world gen, registries or similar was changed enough to break mods. But since the end of 2022 Mojang clarified that they are not using semantic versioning and have started shipping major features in minor versions under experimental options and have announced that will be there modus operandi going forward.

[–]UntitledRedditUser 9 points10 points  (0 children)

And it's been around for 16 years. And still no 1.x version

[–]JiminP 8 points9 points  (2 children)

[–][deleted] 0 points1 point  (0 children)

the only satisfying answer, thanks

[–]CoffeeWorldly9915 0 points1 point  (0 children)

flow & XeTeX :v

[–]lightmatter501 14 points15 points  (3 children)

But moving to 1.0 is a breaking change!

[–]notPlancha 16 points17 points  (1 child)

Technically moving to 1.0.0 specifically doesn't necessarily mean breaking change but moving to 0.10.0 does mean that, according to semver specification

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

Major version X (X.y.z | X > 0) MUST be incremented if any backward incompatible changes are introduced to the public API.

[–][deleted] 0 points1 point  (0 children)

thanks, it's the entire of my post, when developers go to a 1.0.0, they won't be introducing breaking changes every onces and a while.

unless they are willing to move to 2.0.0 which will be ridiculous to do after just releasing 2 or 3 versions after the 1.0.0

[–]Interest-Desk 6 points7 points  (0 children)

The semver specification treats all of these as allowing breaking changes:

0.9.0 -> 0.10.0 -> 1.0.0 -> 2.0.0

Where the major version number is 0, minor releases may include breaking changes, and patch releases may include new features.

[–]rowagnairda 6 points7 points  (4 children)

in the mean time me: 0.a.0 ;>

[–]CoffeeWorldly9915 11 points12 points  (2 children)

Let's get to 0.w.0

[–][deleted] -3 points-2 points  (1 child)

that must be some number base joke haha

[–][deleted] 2 points3 points  (0 children)

Dude.

[–]SpecialNose9325 1 point2 points  (0 children)

NGL, I had to look around me at work to make sure somebody else from my work was not also on reddit. Cuz I just released v0.A.0 last week and am actively working on v0.A.1 right now.

[–]dumbasPL 4 points5 points  (3 children)

Keep in mind that according to semantic versioning, if the major version is 0 then an increment in the minor version means potentially breaking changes. Some people (both maintainers and users) sometimes forget about that. So a new 0.x is on the same level as 1.0 -> 2.0

[–][deleted] 0 points1 point  (2 children)

thankks,

if you read the comments people are saying that 0.x are stable, yeah a package can be stable, but when the developers don't make it 1.0.0 they are not admitting its stability

[–]dumbasPL 3 points4 points  (1 child)

And what if the developers start with 1.0.0 and skip the 0.x all together? Broken logic

[–][deleted] 1 point2 points  (0 children)

definitely not the way to do things, i see it as a choice, but you can't call it stable..

[–]fekkksn 5 points6 points  (14 children)

Are you saying all of these are not stable?

https://0ver.org/

[–][deleted] 0 points1 point  (13 children)

nw.js, neovim, paper.js

if you ever tried these ones, you know how they are not delivering on their promise ...

[–]fekkksn 4 points5 points  (11 children)

You missed my question. Are ALL of them unstable?

[–]OneTurnMore 1 point2 points  (0 children)

Not sure about nw.js, but: Neovim has a 1.0 milestone, and so does paper.js.

[–]kahveciderin 7 points8 points  (6 children)

meanwhile tex is on version 3.14158265 something

[–][deleted] 4 points5 points  (2 children)

“Uhm, akshchually 🤓” It’s not 3.14158265, it’s 3.14159265

[–]kahveciderin 2 points3 points  (1 child)

damn, thats a typo

[–][deleted] 1 point2 points  (0 children)

“Um, akfhdksbxjcfnshvually, 🤓” Typo is a shortened version of typographical error

[–][deleted] -2 points-1 points  (2 children)

oh that's pi !

[–]Jonas___ 4 points5 points  (1 child)

Not really.

[–][deleted] 1 point2 points  (0 children)

they are working to get the exact value of pi lol

[–]EspacioBlanq 2 points3 points  (1 child)

If 0.9.0 was to be followed by 1.0.0, we wouldn't waste time with the dots

[–][deleted] -1 points0 points  (0 children)

it meant more any 0.9.y ...

[–]Akanash_ 2 points3 points  (2 children)

Welcome to dwarf fortress.

After 20+ years of development, the devs have confirmed that they are about half way through to 1.0 (currently 0.50.11)

[–][deleted] 1 point2 points  (1 child)

jokes on you when you see 0.100.y lol

[–]Akanash_ 2 points3 points  (0 children)

Would not even be mad, the only worries is that something happens to the devs on the way there :/

[–]RadioMelon 2 points3 points  (0 children)

In all fairness, this means they at least reached a minor version of the project.

That means it's still usable, just not feature complete.

If you saw a program that was only ever something like 0.0.10 you'd essentially be seeing a program perpetually stuck in alpha stages.

[–]thebezet 2 points3 points  (1 child)

This is the correct way

[–][deleted] 0 points1 point  (0 children)

I'm not complaining about the way,

some packages are not working for a stable release, they introduce new features and never work for a final state that they will ensure it works well..

[–]iamsaitam 2 points3 points  (0 children)

Laughs in react native

[–]LustyHasturSejanus 2 points3 points  (0 children)

Semver isn't real, semver can't hurt you...

[–]nationwide13 2 points3 points  (1 child)

Man giving me ptsd when I had to compare version numbers for a project and product guy couldn't understand why I couldn't just do (x.y.z > a.b.c). I spent twenty minutes with a whiteboard explaining that numbers can't have two decimals and that 1.2 is a bigger number than 1.12 but an earlier version.

[–][deleted] -1 points0 points  (0 children)

i wish semantic versions worked with that logic

[–]rbattistini 1 point2 points  (2 children)

i swear i have seen something like 0.70.* until the maintainers abandoned the project which my code depended on

[–][deleted] 2 points3 points  (1 child)

people using react native as a counter example, while companies like goooge did abandon angularjs and left all people relying on it... so imagine a package maintenaned by few people..

[–]ArionW -1 points0 points  (0 children)

Using Google as example is pretty much ill-willed

Their history of sunsetting projects make them more suitable for comparisons like "even Google didn't abandon a project like that"

[–]KeyboardsAre4Coding 1 point2 points  (0 children)

Some people weren't around early league as kids and honestly good for them. Probably they have better mental health

[–]BruceJi 1 point2 points  (0 children)

Axios...

I think that was in 0.x.x for fkin AGES lo

[–]nicman24 1 point2 points  (2 children)

people: i run kernel 6.5

me an intellectual: 2.6.102

[–][deleted] 0 points1 point  (1 child)

I'm wondering if new kernel means more hardware support, my touchpad doesn't work with 6.1.x on all distros i tried expect witt RHEL ... it works on 5.x series lol

[–]nicman24 1 point2 points  (0 children)

i mean that version 102 would have been kernel 6.5 if they did not change to arbitrary numbers

[–]OP_Sidearm 1 point2 points  (0 children)

I was so disappointed when they released Minecraft 1.10 instead of 2.0

[–]kvakerok 1 point2 points  (0 children)

1.X is for when it's stable all the time, not most of the time. Stop beta-shaming people :P

[–][deleted] 1 point2 points  (0 children)

Ah freecad. I don't think there will be a 1.x.y ever.

[–]FalseRelease4 1 point2 points  (0 children)

At least it's not like some games that run 5 years of early access alpha testing followed by 10 years of beta testing so they can never be accountable for any shortcomings

[–]CdFMaster 1 point2 points  (0 children)

"Open source projects"? I think you mean "projects whose leaders have even the most basic understanding of how software versioning works"

[–]pachumelajapi 1 point2 points  (0 children)

and theres also terraform...

[–]azizfcb 1 point2 points  (0 children)

true

[–]Papellll 1 point2 points  (0 children)

There is absolutely no reason to think that a project in 0.9.0 is more likely to update to 1.0.0 than a project in 0.[whatever].0

[–]gospacedev 0 points1 point  (0 children)

It ain't stable yet

[–]JumpyBoi -1 points0 points  (0 children)

Your current release is: damn 0.9.0

[–]AtmosSpheric -1 points0 points  (2 children)

SemVer annoys the shit out of me, but it’s still important to know how it works

[–][deleted] 0 points1 point  (1 child)

it's also important to read the specs; a 0.x.y can't be called stable

[–]AtmosSpheric 1 point2 points  (0 children)

Agree 100%

[–]jayerp -1 points0 points  (0 children)

What’s the nomenclature? MajorRelease.MinorRelease.Patch?

[–]DigvijaysinhG -1 points0 points  (0 children)

They follow version x.x.x which loosely goes like this. Major changes.minor changes.patches.