3 ms·
What is there to commit to though? There are enough integers to keep bumping the major version every day indefinitely if that's how often your api changes. Also
by jgilias 5y ago
What is there to commit to though? There are enough integers to keep bumping the major version every day indefinitely if that's how often your api changes. Also, no one forces you to support 'deprecated' versions, and the rate of deprecation is completely in the hands of maintainers. It's just nice to have some indication of what's going on between versions.
If something is 'production ready', it's definitely past the '0.y' stage by definition. At least if you actually stick to semver, as '0.y' is explicitly defined as reserved for initial development.
- nickelpro 5y agoBecause a major version of 1.0+ carries the social implication of updates and stability, even if that's not written in the SemVer spec. Many projects want to avoid even the impression of stability
- jgilias 5y agoThis is fine, as long as those projects don't also encourage people to use them in docs and fancy marketing websites. That's just double faced.
- dcow 5y agoSo let’s say you start a project, get 70% there, it’s version roughly 0.7. The project blows up, people get interested, lots of attention is paid to the periphery. Everyone is now using your project but it’s still missing 30% of what you’d consider necessary to be feature complete. What do you do?
- jgilias 5y agoThat's the big misunderstanding here, isn't it? That software must be 'done', 'finished', 'feature complete', etc, in order to have major version number greater than 0. I would (I hope), release version 1.0 soon after I notice people actually using the software, document the existing API, keep releasing new features as minor version updates (1.x), and occasionaly do a major version bump if I see that I must break the existing APIs. As semver prescribes.