
Internal Applications: When Semantic Versioning Doesn't Make Sense - skwashd
https://davehall.com.au/blog/dave/2016/01/19/internal-applications-when-semantic-versioning-doesnt-make-sense
======
fenomas
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.

~~~
skwashd
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.

------
oautholaf
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.

------
alrs
Versioning makes all the difference in the world when you're trying to do
microservices.

This is what makes microservices hard, and this is the unforeseen friction
that kicks people in the ass.

~~~
skwashd
Absolutely. In the article I discuss how important it is to version your
endpoints.

------
ownedthx
A scheme I settled on a previous job that I really liked for internal apps
was:

 _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](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...](http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-
branch-to-project-version-td5543110.html)

------
bottled_poe
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.

~~~
skwashd
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.

