3 ms·

Lots of teams, companies, and general best practice all have policies and/or guidelines around versioning, and its usually something to the effect of wait till

Lots of teams, companies, and general best practice all have policies and/or guidelines around versioning, and its usually something to the effect of wait till the package is 1.0 to use it in production. I think that's why there is always a "race" to the 1.0 I think we should just push for more date based versioning, for instance, CalVer[0] [0]: https://calver.org/ https://calver.org/

earthboundkid 5y ago
All of my Go packages are CalVer v0.year.increment because I'm just a lone developer, so nothing I release can be v1. To be an actual v1, there needs to be a team of people who are committed to keeping a package going indefinitely. I understand why people want to use v1, because it sounds cool and stable, but realistically if you are just releasing code on your own, it is not and cannot be v1.
- zufallsheld 5y ago
  Why would a package released as v1 need to be supported indefinitely?
  - earthboundkid 5y ago
    Because v1 is a social commitment to keeping the API stable and the library working for the foreseeable future. If you don’t want to make that commitment, there’s always v0, which I do in fact use.
paskozdilar 5y ago
Semantic versioning serves a purpose - it makes it possible to automatically update dependencies to the latest compatible version without breaking code. If you don't need automatic updates, then any kind of versioning is fine. Hell, you could get away with just using a single incrementing integer. v1, v2, v3, ..., v225883, etc.
- tsimionescu 5y ago
  That's a terrible purpose, and SemVer does no such thing. There are approximately 0 large libraries that actually offer SemVer style guarantees. For example, the Go stdlib itself is definitely not using SemVer, as it often introduces breaking changes between minor versions. The only thing loose dependencies and automatic version resolution and duplicating libraries achieve is a false sense of security when upgrading code. And the only thing Go's awful, awful idea to force v2+ to change import path is to make a mess in your version control history, and hide the important bits in a sea of needlessly changed files.
- henvic 5y ago
  Semver isn't designed for this, and this whole idea of automatically updating dependencies is awful. Don't do it. Use discretion when updating anything.
  - paskozdilar 5y ago
    Large-scale compatibility is exactly what semver was designed for. > this whole idea of automatically updating dependencies is awful. Yeah, well, that's just, like, your opinion, man.
deleted 5y ago
[deleted]

earthboundkid 5y ago

All of my Go packages are CalVer v0.year.increment because I'm just a lone developer, so nothing I release can be v1. To be an actual v1, there needs to be a team of people who are committed to keeping a package going indefinitely. I understand why people want to use v1, because it sounds cool and stable, but realistically if you are just releasing code on your own, it is not and cannot be v1.

zufallsheld 5y ago
Why would a package released as v1 need to be supported indefinitely?
- earthboundkid 5y ago
  Because v1 is a social commitment to keeping the API stable and the library working for the foreseeable future. If you don’t want to make that commitment, there’s always v0, which I do in fact use.

paskozdilar 5y ago

Semantic versioning serves a purpose - it makes it possible to automatically update dependencies to the latest compatible version without breaking code. If you don't need automatic updates, then any kind of versioning is fine. Hell, you could get away with just using a single incrementing integer. v1, v2, v3, ..., v225883, etc.

tsimionescu 5y ago
That's a terrible purpose, and SemVer does no such thing. There are approximately 0 large libraries that actually offer SemVer style guarantees. For example, the Go stdlib itself is definitely not using SemVer, as it often introduces breaking changes between minor versions. The only thing loose dependencies and automatic version resolution and duplicating libraries achieve is a false sense of security when upgrading code. And the only thing Go's awful, awful idea to force v2+ to change import path is to make a mess in your version control history, and hide the important bits in a sea of needlessly changed files.
henvic 5y ago
Semver isn't designed for this, and this whole idea of automatically updating dependencies is awful. Don't do it. Use discretion when updating anything.
- paskozdilar 5y ago
  Large-scale compatibility is exactly what semver was designed for. > this whole idea of automatically updating dependencies is awful. Yeah, well, that's just, like, your opinion, man.

deleted 5y ago

[deleted]