3 ms·

- 0.0.1 -> improvements - 0.1.0 -> breaking changes - 1.0.0 -> overhaul/refactor needed I know not every case is easy but this is my rule of thumb. I've hone

• Timon3 1y ago
  That kind of goes counter to semantic versioning, where: - x.y.Z (patch) -> backward compatible bug fixes - x.Y.z (minor) -> backward compatible new features - X.y.z (major) -> breaking changes But of course it's fine to use whatever versioning scheme you like, as long as you communicate it to your consumers. https://semver.org/ https://semver.org/ Edit: updated the version strings for clarity.
  • zamadatix 1y ago
    Minor note, but since the topic is accurate semvar: rule 4 specifies 0.x.y is a special case where anything may change at any time.
    • _9y71 1y ago
      Relevant section: https://semver.org/#:~:text=How%20should%20I,next%20major%20version. https://semver.org/#:~:text=How%20should%20I,next%20major%20...
    • Timon3 1y ago
      Good point, if we're already being pedantic we should be accurate. I've updated the version strings in my comment, thanks!
• chrisweekly 1y ago
  Using a 3-digit version like semver, while assigning different semantics, is a recipe for confusion if anyone except you ever refers to a package using this "rule of thumb".
• indrora 1y ago
  0.0.1 - I fixed a bug 0.1.0 - I rearchitected the bug 1.0.0 - The bug is integral to the codebase.
  • i8code 1y ago
    I agree, the initial set of releases were all over the place. I took the feedback from this thread and fed it to Claude along with the semver.org references that were linked here for more detailed (and pedantic) context. Makes way more sense now. Thanks for the feedback! Claude handled the cleanup. Here's the updated releases: https://github.com/derekg/ts-ssh/releases https://github.com/derekg/ts-ssh/releases