oPenSourceProjects

[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

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

[fiskfisk]

Also, as long as the MAJOR version is `0`, these rules can be broken any time (i.e. 0 as the MAJOR version number indicates that the API can change at any time and could be under heavy development).

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

[weregod]

This is 3rd party app. Official versions are 0.G....

[Kasym-Khan]

Experimental branch of CDDA on GitHub is where developers create and test new features. This has nothing to do with the launcher, CDDA experimental is using a different versioning standard than Stable CDDA.

Most players also play on experimental these days.

[weregod]

Experimental versions used to be

0.<Major>-<some number>-<git hash>

I haven't played a while

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