28 ms·

I recognize that this might be a PITA, but for me there is no easy way out of problems related to major versioning, and the clear answer is sticking with versio

by henvic 5y ago

I recognize that this might be a PITA, but for me there is no easy way out of problems related to major versioning, and the clear answer is sticking with version 0.x.x for a considerate amount of time. It seems people rush to publish version 1.0 (or 2.0, etc.) of their libraries, when they'd be better off just sticking with version 0.x. It's not like that a package isn't ready for production because it is < 1.0. It might as well be. If you're an early adopter, I'd say that is even welcome: you're aware that its API might chance, that its quite new, etc. It gives more confidence than a package with version 7.x (at least in informing you that it's prone to changes, and allowing you to make an informed choice), IMHO.

no_wizard 5y ago
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]
heavenlyhash 5y ago
You may be entertained by WarpVer: https://gist.github.com/warpfork/98d2f4060c68a565e8ad18ea4814c25f https://gist.github.com/warpfork/98d2f4060c68a565e8ad18ea481... It's not SemVer(tm). That's it. That's the whole pitch. There's also a section specific to golang, which indeed advocates for sticking with version 0.x.x for a very long time: https://gist.github.com/warpfork/98d2f4060c68a565e8ad18ea4814c25f#warpver-for-golang https://gist.github.com/warpfork/98d2f4060c68a565e8ad18ea481...

by henvic 5y ago

no_wizard 5y ago

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]

heavenlyhash 5y ago

You may be entertained by WarpVer: https://gist.github.com/warpfork/98d2f4060c68a565e8ad18ea4814c25f https://gist.github.com/warpfork/98d2f4060c68a565e8ad18ea481... It's not SemVer(tm). That's it. That's the whole pitch. There's also a section specific to golang, which indeed advocates for sticking with version 0.x.x for a very long time: https://gist.github.com/warpfork/98d2f4060c68a565e8ad18ea4814c25f#warpver-for-golang https://gist.github.com/warpfork/98d2f4060c68a565e8ad18ea481...