3 ms·
I thought about doing that, but I realized that I have no way of knowing how pervasive my next set of changes will be, whether it will warrant a patch or a mino
by moron4hire 4y ago
I thought about doing that, but I realized that I have no way of knowing how pervasive my next set of changes will be, whether it will warrant a patch or a minor version bump. The major ones are much easier to predict; I don't go into them without prior planning. But sometimes, what I think are going to be bug fixes turn out to be API changes. So is 2.19.3 going to go to 2.19.4 or 2.20.0 next week? No clue.
- azundo 4y agoBump it in source to 2.19.4 immediately, and then to 2.20.0 as soon as there is code that requires a minor version bump, then to 3.0.0 as soon as a major version bump is required. Then your version in source is always semver compatible vs by definition being off until you cut the next release as soon as you introduce a breaking change.
- formerly_proven 4y agoThat sounds like a bunch of extra fiddling for a largely inferior solution.