I know pre 1.x.x is kind of a wild west for versioning but uh is there any logic to the version numbers here? I’d think a new feature would be a minor version bump, not patch
The convention in many Rust projects is usually that before 1.0, the patch version behaves like the minor version and the minor version behaves like a major version. So once there are breaking changes, they go to 0.20.0.
This is the case with a lot of apps that follow SemVer, even though it’s not an official part of the spec. It’s not specific to Rust.
The other common thing I see is that if it’s been at 0.x for a long time, the minor version number eventually gets “promoted” to a major version number once the app is stable. For example, React went from 0.14.x to 15.0.0.
That’s my bad really. Currently we’re using the patch semver to denote non-breaking changes, and the minor for breaking.
We’re holding off on a major release until the API reaches stable, which like all open source projects we’re reticent to do because then it puts a lot of pressure on us to match the standard of enterprise-level software developed by a large corporation.
Even though lemmy has many thousands of monthly active users, we’re still really an beta-level software developed by a handful of people.
Honestly, that strategy feels like the most sensible one, since the real world often does not (or can not afford to) care to wait for v1.0.0 before using software. It’s no wonder so many programming ecosystems have adopted it.
I find it a bit of a shame it’s not part of the semver specification itself, which only states:
(paraphrased) do whatever you want haha
My point is, I don’t think that’s “your bad.” It’s just how it is, and the best there currently is. Unless you think there’s something that could’ve been done better, in which case I’m curious as to what, if you’re willing to share.
I know pre 1.x.x is kind of a wild west for versioning but uh is there any logic to the version numbers here? I’d think a new feature would be a minor version bump, not patch
The convention in many Rust projects is usually that before 1.0, the patch version behaves like the minor version and the minor version behaves like a major version. So once there are breaking changes, they go to 0.20.0.
This is correct, and we’ve been following this for lemmy too.
This is the case with a lot of apps that follow SemVer, even though it’s not an official part of the spec. It’s not specific to Rust.
The other common thing I see is that if it’s been at 0.x for a long time, the minor version number eventually gets “promoted” to a major version number once the app is stable. For example, React went from 0.14.x to 15.0.0.
That’s my bad really. Currently we’re using the patch semver to denote non-breaking changes, and the minor for breaking.
We’re holding off on a major release until the API reaches stable, which like all open source projects we’re reticent to do because then it puts a lot of pressure on us to match the standard of enterprise-level software developed by a large corporation.
Even though lemmy has many thousands of monthly active users, we’re still really an beta-level software developed by a handful of people.
Honestly, that strategy feels like the most sensible one, since the real world often does not (or can not afford to) care to wait for v1.0.0 before using software. It’s no wonder so many programming ecosystems have adopted it.
I find it a bit of a shame it’s not part of the semver specification itself, which only states:
My point is, I don’t think that’s “your bad.” It’s just how it is, and the best there currently is. Unless you think there’s something that could’ve been done better, in which case I’m curious as to what, if you’re willing to share.