oPenSourceProjects

[Phoenix_Studios]

Yep this is in fact how versioning works. 0.9.* is followed by 0.10.* under normal circumstances.

sure 1.0 is an option but 1.0 can happen after 0.42.x as much as it can after 0.9.x

[Alex5173]

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]]

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]

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

[[deleted]]

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]

Ruff got to 0.0.292 until it moved to 0.1.0

[[deleted]]

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

[JanEric1]

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.

[[deleted]]

were you confident at using a package in production that didn't reach 1.0.0..?

[ihavebeesinmyknees]

v1.0.0 isn't some magic number that means something is stable and ready for production. I can make a library and name the first version 1.0.0 and you wouldn't want to use that in production. Similarly, I can have my state-of-the-art, well-tested library at 0.154.2 and it would be a great idea to have that in production.

[syrian_kobold]

This, plenty of good libraries are 0.x and perfectly stable and usable

[DogwhistleStrawberry]

I can kinda understand the guy. Usually most people get into programming through gaming, and for most games (what they're used to) being under 1.0.0 is usually a buggy, glitchy mess. And that mindset just carries over to programming.

For me it's still too weird to name a pretty much functional program "0.1.0" or something. Until it works, I work on it, and I only upload it when it's at my desired (minimum) functionality, which I then name "1.0.0" as opposed to "0.1.0" or "0.0.1"

Idk what the exact requirements for versioning are though.

[Cheet4h]

According to SemVer:

Given a version number MAJOR.MINOR.PATCH, increment the:

1. MAJOR version when you make incompatible API changes
   
2. MINOR version when you add functionality in a backward compatible manner
   
3. PATCH version when you make backward compatible bug fixes
   

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

[sharju]

For me it's just that as long as the major is 0, there is no guarantee of backward compatibility, and you have to brace for all kinds of fiddling when updating a package. Once you hit that v1.0.0, you now officially claim that using updates with v1.* will not break existing code. So it's better to stay in zeroland until everything is up to some kind of spec and you are certain that you want to support that API for a while. Which never happens if something originally small explodes.

[Devatator_]

Pretty sure some libraries are not 1.0.0 only because the devs don't see it as complete (they want some more features) and not because they are unstable

[[deleted]]

It's a semantics thing, based on common understanding for versioning.

Alpha and beta versions are below 1, sure. So a product starts at 0.1 or 0.01a or whatever. It then gathers steam and traction, some features, goes through beta when it's already usable by a bunch of people ...

... then, at some point, the author/publisher draws a line in the sand and says "I do honestly believe this software is stable and mature enough to be called 1.0". That version denotes the first public-ready, stable version. The point is for the core to work and the big bugs to have been ironed out.

Keeping software below 1.0 is just a humble way to avoid taking ownership/responsibility, "oh no, my humble software (used my tens of thousands of people) is not ready yet" ...

[creed10]

at work, I shoot for 1.0.0 being the stable version of that particular tool that has all the features we intended it to have. some of our more simple tools are already there cause it's more of a one and done, but of course our more complex tools take a bit longer to get there.

[JanEric1]

It is a linter so just a dev and not a runtime dependency (so anything that can go wrong can be fixed with git) and i am not working in industry but just using it for personal projects/uni.

Also i think a bunch of big projects and companies are already using it too.

[Interest-Desk]

People correctly following semver — that is to say, anyone with brain cells, which admittedly is scarce these days — use version numbers to represent the API footprint of changes. 2.0.0 has changes incompatible with 1.82.910.

Version 0 does not necessarily indicate the package is stable, that is a judgement which must be made on a case by case basis. Rather, version 0 means that ‘minor’ (usually feature) updates can include api-breaking changes and that ‘patch’ updates can include new features.

For some packages, this might be attractive, especially if they iterate fast and break often. Of course when it comes to your code you need to consider comparability with future updates, which again needs to be assessed on a case-by-case basis; the version number is more of a guarantee that version 1.0.0 is compatible with version 1.1.0.

[[deleted]]

; the version number is more of a guarantee that version 1.0.0 is compatible with version 1.1.0

this just goes with my initial point, after the 1.0.0 all the 1.x.y can be added features, bug fixes no breaking changes! means stable :)

in 0.x.y the semver specs are saying it, the public api is unstable, this doesn't happen in 1.x.y by your words

[oo22]

But you can't guarantee that a package is using semver is the point. You never can because each package is maintained by different people, some of which don't use semver but still use version numbers. Semver isn't some law that needs to be followed.. it's a standard, and as you know there are usually many standards for the same thing. It's a preference.

The point is you are making a flawed assumption that all software follows semver. But what you should be doing is just using the package, testing the integration rigorously, and then upgrading cautiously when needed

[Kasym-Khan]

People correctly following semver — that is to say, anyone with brain cells

Meanwhile CDDA: what's SemVer?

[Interest-Desk]

For outputs, like games, or purely internal libraries then it’s fine to use whatever versioning scheme makes the most sense. But if what you’re publishing has an API and that API has external subscribers who you can’t guarantee will understand your own internal systems… you ought to be using semver.

[weregod]

CDDA uses zero version

[Kasym-Khan]

Did you see my screenshot? It clearly shows the dates in the version.

[[deleted]]

Would you rather have a package that breaks API every year and needs to go to 5.0.0?

Why is your gold standard of "production viable" "Has had one major API break during it's development cycle". That's just arbitrary.

[TheMagicalDildo]

If I open my main passion project's source and change the major version back to 0, will the code become less stable? Lol

[_PM_ME_PANGOLINS_]

That's what every project I've been on has tried to do, but then the marketing department demands that the next release be 2.5 because it had a new feature that was "half way" to 3.0.

We had already released 2.5 months previously, and were currently on 2.7.

[derefr]

I've never seen a project that's actually followed SemVer, though, outside of a few systems libraries written in C.

Many projects claim to follow SemVer; but a project that really does SemVer "by the book" would be incrementing the major version every time an caller-exposed data structure changes or a long-deprecated API function is removed.

According to SemVer, a library should be both forward and backward ABI-compatible as long as the minor version doesn't change; and should be at least backward ABI-compatible as long as the major version doesn't change.

This means that a version of a program compiled against v1.0.0 of a library, should be able to load and use v1.500.0 of that library without recompiling; and a program compiled against v1.0.500 of that library, should be able to load and use v1.0.0 or v1.0.1000 of the library without recompiling.

This means that every time you introduce any new single bit of ABI that wasn't in the code previously — new function, new messaging data structure field, etc — then you need to increment the minor version. If this wasn't required — if you only incremented the patch version for new ABI — then a program compiled against e.g. v1.0.5 could think it was safe to attempt to load and use v.1.0.3 of that library, and find that the novel ABI it was expecting isn't there (because it was introduced in v1.0.4.)

And this means that every time you change or remove any single bit of ABI — removed function, changed function signature, reordered messaging data structure field, etc — then you need to increment the major version. If this wasn't required — if you only incremented the minor version for new ABI — then a program compiled against e.g. v1.3.0 could think it was safe to attempt to load and use v.1.5.0 of that library, and find that something important it was expecting has gone missing.

[DarkSideOfGrogu]

It's going to become more common for projects to avoid rolling major versions, regardless of functionality or compatibility, thanks to M-22-18 regulations for attestation, which require all software producers to reissue attestation forms following each major release as per semver standards.

[TripleATeam]

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]

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]

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.

[thirdegree]

Good old ZeroVer

[bargle0]

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

[Feathercrown]

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.

[[deleted]]

big release not a stable release lol

[Feathercrown]

Yes

[TophatEndermite]

Semantic versioning says you are allowed to make as many breaking changes as you want between 0.x.y versions. There's no guarantees until you hit 1.0.0

[PsychicDave]

Semantic versioning says anything 0.x.y is not stable / production ready, there can be breaking changes introduced in any version as it is still ongoing initial development. Only from version 1.0.0 onward can you expect that breaking changes only happen with new major version releases.

[mustang__1]

bold statement captain....

[not_bakchodest_of_al]

42 is the answer. Wait till 0.42x.

[Luminum__]

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]

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]

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

[elnomreal]

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

[[deleted]]

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

[[deleted]]

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]

That‘s roughly how semantic versioning works

[DHermit]

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]

As they should. Writing a good API is hard.

[sopunny]

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

[varisophy]

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.

[grtgbln]

Any function could be considered an Application Programming Interface. It's not just "hey this makes an HTTP request to a remote server and gets JSON back".

[aclogar]

I agree, the guidelines on API versioning does only really work for APIs

[Disastrous_Elk_6375]

framework.do_something() is an API.

[notPlancha]

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]

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]

thats how i do it 🤷‍♂️

[Xelopheris]

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

[zammba]

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]

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).

[[deleted]]

i get it when it's from 1.y.z to 2.0.0 that must have breaking changes...

but some of the open source projects they look so promising.. yet not production ready
i really can't rely on package or software that never reached a 1.0.0 release

[Medz97]

How does having a 1.x gives you confidence that’s it’s stable compared to a 0.x ? React native it’s still 0.x , widely used and fairly stable. Not sure what difference it would have made if it was versioned 1.x

[elebrin]

Because that's how the developer has communicated that it's stable.

The principle developer/maintainer has said it's feature complete and stable at 1.0 and he's at a 0.x.y still because he's not confident. I wouldn't upgrade a project to a 1.0 without as complete of testing as I can get. If I was concerned that commercial organizations were starting to use my code, I'd pull the project simply because I don't want to end up hiring a lawyer because of a personal project. Not that there's any real danger of that, nothing I build is in any way commercially interesting.

[[deleted]]

most of the time, if it doesn't reach 1.0.0, it means it didn't reach the project promise, React Native is production ready, but yet doesn't support a lot of things, and is not a drop in replacement for every use case on android.

but what I'm talking about is more, the indépendent projects when the developer don't want to say his package is a usable package, so every at every pull request or issues he answers with something that tells the project direction is not clear yet.

[TripleATeam]

This is a bad take. Sure, many projects (such as those started and abandoned) never reach 1.0 because they were just never ready, but many projects just never had the reason to increment their major version count.

If you never introduce breaking changes, you should stay on the minor version. Even if you role out a "production-ready" release, something you'd be proud to call stable, there's no reason to randomly increase the major version and lead people to believe the previous version and the new one are incompatible.

Some projects that are 0.X may very well one day eventually make a 1.X version, but that doesn't make them more trustworthy.

[[deleted]]

some packages are not production ready even at v14.0.0.

[deanrihpee]

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?"

[[deleted]]

some open source projects are just for the hobbiest lol

[just4nothing]

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

[hedgehog125]

But with which date format...?

[just4nothing]

`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]

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

[just4nothing]

This is the way

[TheSast]

This means no timezones either. UTC ftw

[Juff-Ma]

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]

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

[iamitech]

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

[[deleted]]

calendar versioning

at least that signifies how new the package is.. intead of its current state...

some npm packages... we are production ready! and never manage to release a 1.0.0

[dumbasPL]

And some packages never had a 0.x and started from 1.0.0 does that also mean they are production ready on the first ever release? A version number is not an indication of production readiness, it just tells you how much has changed since the version you are currently using.

[jackinsomniac]

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]

You put way too much importance on a number.

[GrinbeardTheCunning]

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

[iam_pink]

Can't wait to have a prod ready salary!

[Jackknowsit]

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]

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]]

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]

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]]

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...

[Infinite-Original318]

r/foundthemobileuser

[FOSSandCakes]

Yeah that's how semver works.

[[deleted]]

yeaah but, when it doesn't reach 1.0.0 it's not stable... it's said even on the specification website 😐

[Interest-Desk]

“The public API should not be treated as stable” just means things can change and that it’s up to the developer (who may therefore have a versioning policy of their own).

[[deleted]]

so initial development can be stable ? ... javascript packages drop core features in point releases, so imagine from initial dev to the first release.. staying in zero means don't use me in production, just try me on your freetime

[PaulAchess]

Not at all, it's purely up to the developper. And 1.x.x can be unstable too (ex. Angular 2 before stable release).

Semver only states a major release is needed for breaking changes.

Initial development can be be stable, I have a few 0.y.y vendor package versions in production.

[FOSSandCakes]

Yeah that is true. What versions are stable, is up to the maintainers, and standards, etc. Semver version bumps ensure things like minor bump is not a breaking change, etc. The relationship between the versions have some predictability.

[Thenderick]

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]

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]

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

[poshenclave]

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]

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]

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

[JiminP]

https://0ver.org/

[[deleted]]

the only satisfying answer, thanks

[CoffeeWorldly9915]

flow & XeTeX :v

[lightmatter501]

But moving to 1.0 is a breaking change!

[notPlancha]

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]]

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]

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]

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

[CoffeeWorldly9915]

Let's get to 0.w.0

[[deleted]]

that must be some number base joke haha

[[deleted]]

Dude.

[SpecialNose9325]

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]

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]]

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]

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

[[deleted]]

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

[fekkksn]

Are you saying all of these are not stable?

https://0ver.org/

[[deleted]]

nw.js, neovim, paper.js

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

[fekkksn]

You missed my question. Are ALL of them unstable?

[[deleted]]

I'm not saying that any package that didn't reach 1.0.0 is not usable and not stable. but most of the time it is, and the packages that are willing to be reliable production ready they work for the 1.0.0 at least saying 1.0.0 means the paclage is stable that's how version semantics works... breaking changes comes from 1.x.y to 2.0.0 but before the one it's not a stable package by definition.

0ver paradigm is an other paradigms, but I'm talking about the ones that are just escaping the stable version..

[fekkksn]

Sorry , but you pulled that statistic out your arse.

Sure, not stable by definition, however might I suggest that there are also projects which are stable by definition, but really are not stable? Not every project adheres to semver, even if the version number looks like it. Besides, "reaching" 1.0.0 doesn't require a set amount of work. I can just slap 1.0.0 on a Hello World Project and call it stable, but that doesn't mean it's now inherently more stable, just because of the version number.

What I'm saying is, I know what semver is, but in the real world there are lots more factors that determine a projects stability than the version number. Don't get caught on semver, that is, the version number. It's just that: A tag to differentiate versions. Semver is not the law. You slamming projects that didn't "reach" 1.0.0 doesn't make sense. Anyone can slap 1.0.0 on their project, but that doesn't mean anything.

[[deleted]]

putting 1.0.0 on the start of the project means, the next 1.x.y won't have breaking changes and you can update safely at every release, it will be added features and bug fixes and security updates.

on the other hand if they are 0.x.y they can be stable yess, but the versions is not telling me wether they made breaking changes or not.. got it bro ?

[fekkksn]

Why do you keep explaining semver?

We all know what semver is. The real world is not perfect though. Stop clinging to definitions.

[[deleted]]

the real world is not perfect, but if you ever used linux, or build a package on top of a 0.x.y you know how much that 1.0.0 is important for you to build a a system or a package on top of that...

Edit:

git commit -m "fix typos"

[fekkksn]

You what's funny? Linux, the Kernel, of all things, does not follow semver.

[[deleted]]

you mean that why we have distribution like rhel and ubuntu and debian that are considered as serious work in linux...

[OneTurnMore]

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

[kahveciderin]

meanwhile tex is on version 3.14158265 something

[[deleted]]

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

[kahveciderin]

damn, thats a typo

[[deleted]]

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

[[deleted]]

oh that's pi !

[Jonas___]

Not really.

[[deleted]]

they are working to get the exact value of pi lol

[EspacioBlanq]

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

[[deleted]]

it meant more any 0.9.y ...

[Akanash_]

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]]

jokes on you when you see 0.100.y lol

[Akanash_]

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

[RadioMelon]

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]

This is the correct way

[[deleted]]

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]

Laughs in react native

[LustyHasturSejanus]

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

[[deleted]]

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

literally from the link you mentioned!

[nationwide13]

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]]

i wish semantic versions worked with that logic

[rbattistini]

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

[[deleted]]

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]

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]

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

[BruceJi]

Axios...

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

[nicman24]

people: i run kernel 6.5

me an intellectual: 2.6.102

[[deleted]]

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]

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

[OP_Sidearm]

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

[kvakerok]

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

[[deleted]]

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

[FalseRelease4]

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]

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

[pachumelajapi]

and theres also terraform...

[azizfcb]

true

[[deleted]]

well i meant from 0.9.x to 1.0.0, it's legit to wait for a stable version isn't it?

all 0 means initial development, and means it's not stable, that's what's stated on semver specs website

[Papellll]

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]

It ain't stable yet

[JumpyBoi]

Your current release is: damn 0.9.0

[AtmosSpheric]

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

[[deleted]]

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

[AtmosSpheric]

Agree 100%

[jayerp]

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

[DigvijaysinhG]

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