This article seems to miss the point of SemVer. Quoting the spec: "1. Software using Semantic Versioning MUST declare a public API." If one is talking about a website or a GUI application, SemVer doesn't apply in the first place.
After all, the point of the thing is to solve dependency hell - it's only meaningful for things that other code can declare dependencies against.
You're right, I should've quoted that in the article. My post is a reworked version of my arguments against a client's proposal to implement SemVer for everything.
I was able to convince them not to use it for what were defined as internal apps in my proposal.
Inside an organization, separate repos and versions can simply be unnecessary overhead. As long as you can have an edict from above that 'thou shall not break the build or its tests for you or your dependants; the punishment is immediate rollback', empower some people to enforce this, and have plenty of automated tests, distinct repos and versions are silly, unnecessary and massively inessential overhead.
But if you don't have that balkanization is a reasonable option.
Because of this, I could say, 'use the latest artifact on the develop branch', or, I could say 'use exactly master-103'. Those two alone were pretty powerful.
By the way, I asked Maven devs if this would numbering scheme would possible (at the time, I would have happily used Maven instead of Ivy because I had to build some tooling to use Ivy); they were strongly against the idea: http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-curre...
I guess it depends how much quality control you want to implement. Author seems to be suggesting next to zero user acceptance testing, which is probably fine for small applications.
I'm sorry you were left with the impression that I was advocating little or no quality control. I believe in quite the opposite, but I don't think someone should need to conduct manual testing and sign off at the end of the process.
Human testing should occur during development. Users should play with prototypes and provide feedback, humans should help define automated acceptance tests. A machine should run the tests and throw the code over the wall, people are no longer needed for that.
[+] [-] fenomas|10 years ago|reply
After all, the point of the thing is to solve dependency hell - it's only meaningful for things that other code can declare dependencies against.
[+] [-] skwashd|10 years ago|reply
I was able to convince them not to use it for what were defined as internal apps in my proposal.
[+] [-] oautholaf|10 years ago|reply
But if you don't have that balkanization is a reasonable option.
[+] [-] alrs|10 years ago|reply
This is what makes microservices hard, and this is the unforeseen friction that kicks people in the ass.
[+] [-] skwashd|10 years ago|reply
[+] [-] ownedthx|10 years ago|reply
branch-buildno
Where branch is the git branch, and buildno came from our build machine (Jenkins in our case).
examples:
* develop-5
* master-10
I then used this ivy-based project: https://github.com/sethcall/depends to push those dependencies to our own internal artifact repository.
Because of this, I could say, 'use the latest artifact on the develop branch', or, I could say 'use exactly master-103'. Those two alone were pretty powerful.
By the way, I asked Maven devs if this would numbering scheme would possible (at the time, I would have happily used Maven instead of Ivy because I had to build some tooling to use Ivy); they were strongly against the idea: http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-curre...
[+] [-] bottled_poe|10 years ago|reply
[+] [-] skwashd|10 years ago|reply
Human testing should occur during development. Users should play with prototypes and provide feedback, humans should help define automated acceptance tests. A machine should run the tests and throw the code over the wall, people are no longer needed for that.
[+] [-] kyllo|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]