3 ms·

The rules for bumping to 1.0.0 are based on hindsight ("probably already be 1.0.0"), exogenous factors ("users") and human emotion ("worrying a lot"). It would

The rules for bumping to 1.0.0 are based on hindsight ("probably already be 1.0.0"), exogenous factors ("users") and human emotion ("worrying a lot"). It would be impossible for a computer to correctly bump a piece of software to 1.0.0, and humans mostly get it wrong too.

coldtea 11y ago
Well, it's not as if "1.0.0" is meant to offer any logical and universal guarantees for code quality, completeness, etc. compared to, say, 0.7.x -- apart from what semver asks for. So, as long as it is relatively stable when bumped to 1.0.0, and later releases follow to major/minor rules of semver, it doesn't matter much.
- manyxcxi 11y ago
  For all of our internal projects we don't push to production til 1.0.0- but because people have different opinions and we live in the world at large we don't have a hard rule of using someone else's code < 1.0.0. We'd just be missing out on too many useful projects. If it the major version changes for us, the API has probably changed. If it's a minor version bump, the API has DEFINITELY not changed. Rev changes are your typical bug security/performance fixes that are limited in scope. Who decides all this? If there's any question, just pick the more important signal of the two.
jrochkind1 11y ago
For stuff I write, as soon as _I_ am using it in production, it's 1.0. That's pretty straightforward and objective. Sometimes I give it a couple weeks in production myself as a beta/rc before I tag it 1.0, to take the pain of early bugs myself instead of foisting it on others. No more than that. It's not always that simple, and it may not be totally objective down to the timestamp, but we can think of _many_ cases where people kept an 0.x version number _long_ after it was obvious they shoudln't be -- the authors were using it in production, they knew hundreds or thousands of developers were using it in production, they knew they _were_ thinking of backwards compatibility. React was my prime example before now. The problem isn't different judgements on grey areas, the problem is people completely ignoring the intent of the 0.x versioning -- so they can maybe sort of pretend they are doing semver, while not doing it at all. The first time you realize you can't make an enormous backwards compatible change without telling anyone, or you're a jerk -- is another good milestone. Who cares if sometimes it could have been somewhat earlier or later. I'm pretty sure if everyone actually tried, it'd work out orders of magnitude better. If 0.x versions just "weren't allowed", it doesn't _reduce_ the temptation people have _not_ to do semver. 0.x is just a big advertisement "We're NOT using semver... yet, but plan to later. And also this software is super unstable and you really ought not to use it in production" And should be understood thusly. The problem is when people keep using 0.x, but are clearly _not_ sending that signal. Those people should be shamed.

coldtea 11y ago

Well, it's not as if "1.0.0" is meant to offer any logical and universal guarantees for code quality, completeness, etc. compared to, say, 0.7.x -- apart from what semver asks for. So, as long as it is relatively stable when bumped to 1.0.0, and later releases follow to major/minor rules of semver, it doesn't matter much.

manyxcxi 11y ago
For all of our internal projects we don't push to production til 1.0.0- but because people have different opinions and we live in the world at large we don't have a hard rule of using someone else's code < 1.0.0. We'd just be missing out on too many useful projects. If it the major version changes for us, the API has probably changed. If it's a minor version bump, the API has DEFINITELY not changed. Rev changes are your typical bug security/performance fixes that are limited in scope. Who decides all this? If there's any question, just pick the more important signal of the two.

jrochkind1 11y ago

For stuff I write, as soon as _I_ am using it in production, it's 1.0. That's pretty straightforward and objective. Sometimes I give it a couple weeks in production myself as a beta/rc before I tag it 1.0, to take the pain of early bugs myself instead of foisting it on others. No more than that. It's not always that simple, and it may not be totally objective down to the timestamp, but we can think of _many_ cases where people kept an 0.x version number _long_ after it was obvious they shoudln't be -- the authors were using it in production, they knew hundreds or thousands of developers were using it in production, they knew they _were_ thinking of backwards compatibility. React was my prime example before now. The problem isn't different judgements on grey areas, the problem is people completely ignoring the intent of the 0.x versioning -- so they can maybe sort of pretend they are doing semver, while not doing it at all. The first time you realize you can't make an enormous backwards compatible change without telling anyone, or you're a jerk -- is another good milestone. Who cares if sometimes it could have been somewhat earlier or later. I'm pretty sure if everyone actually tried, it'd work out orders of magnitude better. If 0.x versions just "weren't allowed", it doesn't _reduce_ the temptation people have _not_ to do semver. 0.x is just a big advertisement "We're NOT using semver... yet, but plan to later. And also this software is super unstable and you really ought not to use it in production" And should be understood thusly. The problem is when people keep using 0.x, but are clearly _not_ sending that signal. Those people should be shamed.