3 ms·

To make things worse: sub one-point-zero versions don't actually need to mean anything, i.e. 0.0.1 -> 0.0.2 could be a breaking change as far as the semver spec

by lhorie 6y ago

To make things worse: sub one-point-zero versions don't actually need to mean anything, i.e. 0.0.1 -> 0.0.2 could be a breaking change as far as the semver spec is concerned. Library authors often stay in 0.x ranges "just in case the API needs to change". And before anyone claims one shouldn't use stuff on versions below 1.0, consider that very popular projects like React were widely deployed in production before they decided to bump themselves out of 0.x...

perlgeek 6y ago
This is reminiscent of gmail staying in "beta" for 5 years and having acquired 10 million users. > And before anyone claims one shouldn't use stuff on versions below 1.0, consider that very popular projects like React were widely deployed in production before they decided to bump themselves out of 0.x... I agree. It's pretty easy to advise people not to use library with low version numbers, but then what do you use instead? Not every ecosystem out there has libraries for all common task, and if you need to, say, fill out a PDF form in language $X, and your choice is either a v0.5.22 library or writing it from scratch, I know I'd go for the v0.5.22... (especially with deadlines looming, and me having other things to do than reinvent the wheel).
dragonwriter 6y ago
> To make things worse: sub one-point-zero versions don't actually need to mean anything. I think SemVer would be improved if 0.x versions were treated exactly like 1.0+ versions except that all minor versions had the semantic guarantees (none, that is) of major versions (but patches still had patch semantics.) > Library authors often stay in 0.x ranges "just in case the API needs to change". It's a problem that library authors don't want to commit to API stability and clearly differentiating breaking changes, but it's not a problem with SemVer that it makes it easy for them to notify of this intent in an unambiguous manner.

by lhorie 6y ago

perlgeek 6y ago

This is reminiscent of gmail staying in "beta" for 5 years and having acquired 10 million users. > And before anyone claims one shouldn't use stuff on versions below 1.0, consider that very popular projects like React were widely deployed in production before they decided to bump themselves out of 0.x... I agree. It's pretty easy to advise people not to use library with low version numbers, but then what do you use instead? Not every ecosystem out there has libraries for all common task, and if you need to, say, fill out a PDF form in language $X, and your choice is either a v0.5.22 library or writing it from scratch, I know I'd go for the v0.5.22... (especially with deadlines looming, and me having other things to do than reinvent the wheel).

dragonwriter 6y ago

> To make things worse: sub one-point-zero versions don't actually need to mean anything. I think SemVer would be improved if 0.x versions were treated exactly like 1.0+ versions except that all minor versions had the semantic guarantees (none, that is) of major versions (but patches still had patch semantics.) > Library authors often stay in 0.x ranges "just in case the API needs to change". It's a problem that library authors don't want to commit to API stability and clearly differentiating breaking changes, but it's not a problem with SemVer that it makes it easy for them to notify of this intent in an unambiguous manner.