

I'm tired of SemVer. This looks way better - ScottWRobinson
http://tenver.org/

======
lucozade
I worked at a place where the version numbers were largely chosen by the CEO
for marketing reasons. He'd keep them low for brand new stuff to excite the
early adopters then bump the major version up a 5 or so when he wanted to sell
to more conservative types.

I was, by chance, at a client once where they were having a big meeting
discussing how much testing etc was required to make a "big" upgrade. I had to
point out that, in fact, the difference between the 2 versions was a few minor
bug fixes largely in code they didn't use.

They weren't very happy.

When I got back to the office I, somewhat tongue in cheek, suggested we allow
the clients to choose their own versioning systems. I still think it would be
better than what we had.

------
copsarebastards
Do people actually have trouble with semantic versioning? It seems like such a
simple thing to have trouble with.

~~~
killface
It's not that we have trouble with it-- it really is pretty simple. It's that
there can be a bunch of rules around it that make it not simple.

For example, how do you evalute postfix addition? If you have v1.0.0-alpha3
and v1.0.0-alpha10, are all semver implementations supposed to do an
alphabetical check until it sees a string? Or should you zero-pad anything
with text postfixes? And how do you deal with labeling branches or
architectures?

Internally, we no longer use semver, we use the build number as the version,
and the commit hash as the input to the deploy systems.

~~~
copsarebastards
> For example, how do you evalute postfix addition? If you have v1.0.0-alpha3
> and v1.0.0-alpha10, are all semver implementations supposed to do an
> alphabetical check until it sees a string? Or should you zero-pad anything
> with text postfixes?

That's not semantic versioning. Semantic versions are for communicating
feature additions and breaking changes to technical users. Alpha/beta are for
marketing and communicating stability to nontechnical users.

If you're releasing to a large user base, there's no reason to do more than
1.0 alpha and 1.0 beta before 1.0. Releasing a ton of times before your big
release causes a lot of deploy thrashing that's pointless. Unless your user
base is truly gigantic, I'd even be hesitant to release an alpha.

If you're releasing personalized changes to a few clients, then alpha/beta
don't make sense: they don't care about a general sense of reliability, they
care about features they've requested, so just tell them, "This is the release
with X feature you are interested in."

Internally, there will always be technical users who might fine use in
semantic versioning. If you're doing alpha/beta, 1.0 alpha can be 1.0.5 and
1.0 beta can be 1.0.23 and 1.0 can be 1.0.75. Similarly, changes delivered to
specific users can just be specific files earmarked for them.

> And how do you deal with labeling branches or architectures?

Why are you tagging branches with a version number? Version numbers are for
stable, tested, cohesive, coherent code points, not for whatever random state
exists in version control. If you're trying to map version numbers to your git
tree, _of course_ that doesn't work: git trees are complex. A semantic version
should only ever correspond to a stable point in your "source of truth"
branch. A version is a commitment that the versioned code point is something
you're willing to support and put your name on.

There are a few ways to deal with different architectures. If you have
architectures that are relatively synced and coming from the same codebase,
just version them the same: 1.0.1 for Mac and 1.0.1 for Windows are the same,
they're just different files from the same release. If your architectures are
drastically different (Mac is far behind Windows, for example) then version
them as separate products: 1.0.1 for Mac can release at the same time as 2.1.5
for Windows.

------
dominotw
Take a look at Elm packages. Solves all the issues with current semvar without
inventing a new solution.

~~~
JadeNB
Did you read the article? I don't think it's really proposing a new solution.

------
yami
And that's how you end up with Java...

