▲ | ramon156 2 days ago | ||||||||||||||||||||||
- 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 honestly never needed a major version change | |||||||||||||||||||||||
▲ | Timon3 2 days ago | parent | next [-] | ||||||||||||||||||||||
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. Edit: updated the version strings for clarity. | |||||||||||||||||||||||
| |||||||||||||||||||||||
▲ | chrisweekly 2 days ago | parent | prev | next [-] | ||||||||||||||||||||||
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 2 days ago | parent | prev [-] | ||||||||||||||||||||||
0.0.1 - I fixed a bug 0.1.0 - I rearchitected the bug 1.0.0 - The bug is integral to the codebase. | |||||||||||||||||||||||
|