3 ms·

Except that using a build number in the way you're describing is just a worse semantic version. You now have no way to indicate if your changes are breaking. Se

Except that using a build number in the way you're describing is just a worse semantic version. You now have no way to indicate if your changes are breaking. Separation of your pipelines also just got a lot more hectic because you could have a situation where you don't know what happened when you're missing "versions" (builds) because it's failing but still incrementing... Using build numbers for versioning doesn't really work in a large ecosystem and often relies on picking the latest of a branch or having to sift through builds when deploying to find the right one.

treis 5y ago
I think the concept of a breaking change is part of the mistake. If you want to change something you should introduce the new way and support it side by side with the old for a while while going through a depreciation cycle. I'm with the GP on this. Pinning to a specific version is a code smell. You should have enough confidence in your regression suite to always use the latest version. And hopefully enough confidence in your vendors that they're not going to break a bunch of stuff.
- joombaga 5y ago
  The concept only makes sense in the context of APIs. I don't know if that's obvious; I've seen people use semantic versioning with software that didn't have public interfaces. Even if you go through a deprecation cycle, you're still going to eventually have a build N with feature X, and build N+1 without feature X. That's a breaking change.
  - treis 5y ago
    That's true in the sense that a bullet flying at you and steam roller running you down both represent mortal threats. But practically a reasonable depreciation cycle isn't going to be a breaking change because everyone will have plenty of time to upgrade.
sokoloff 5y ago
> You now have no way to indicate if your changes are breaking. You now have no way to indicate that you know your changes are breaking.
thrower123 5y ago
Your build number tags the source control commit it was built from in any reasonably sanely implemented CI/CD system.

treis 5y ago

I think the concept of a breaking change is part of the mistake. If you want to change something you should introduce the new way and support it side by side with the old for a while while going through a depreciation cycle. I'm with the GP on this. Pinning to a specific version is a code smell. You should have enough confidence in your regression suite to always use the latest version. And hopefully enough confidence in your vendors that they're not going to break a bunch of stuff.

joombaga 5y ago
The concept only makes sense in the context of APIs. I don't know if that's obvious; I've seen people use semantic versioning with software that didn't have public interfaces. Even if you go through a deprecation cycle, you're still going to eventually have a build N with feature X, and build N+1 without feature X. That's a breaking change.
- treis 5y ago
  That's true in the sense that a bullet flying at you and steam roller running you down both represent mortal threats. But practically a reasonable depreciation cycle isn't going to be a breaking change because everyone will have plenty of time to upgrade.

sokoloff 5y ago

> You now have no way to indicate if your changes are breaking. You now have no way to indicate that you know your changes are breaking.

thrower123 5y ago

Your build number tags the source control commit it was built from in any reasonably sanely implemented CI/CD system.