
Progressive Versioning - timblair
http://allinthehead.com/retro/373/progressive-versioning
======
jpollock
Version numbers are for marketing and legal. They are used as a way to bundle
sets of features together and give them a name "You need to upgrade to X.Y.Z,
$$ plz", and "If your version is older than X.Y.Z, you are no longer
supported, go away or pay us lots of money. K thx bye". Marketing may place
additional rules "Customers on X.Y.Z should be able to upgrade to A.B.C by
clicking a button and giving us money.", but it's still owned by marketing (or
at least the person wearing that hat).

Software engineers should only care about the information required to create a
reproducible build. For that, all they need is a single value, be it a number,
a hex string, or a name.

Resist the temptation to let the marketing team know about the internal build
numbers. That way leads to madness. We went from a single version number to a
5 digit dotted number all because people kept putting the internal number into
contracts and we had to inject new releases with the same marketing number. DO
NOT DO THIS - it leads to madness!

Frequently the dotted number will map onto software branches, but don't link
them directly - again, that limits your flexibility and (if completely
artificial) will result in unnecessary code drift when the branches inevitably
diverge over 5yr+maintenance contracts.

~~~
emergentcypher
> Version numbers are for marketing and legal.

This this this this this. This.

I've been burned by not doing this in the past with a boss who liked to make
huge jumps and changes to version numbers without telling his devs, and then
not being able to reproduce a given build.

Take a look at the versioning/about screens of some major software, and you'll
often see these internal build numbers which have nothing to do with the shiny
new "Version 2.0" that's on the branding.

Marketing can call it a Totally New Name v10, to us it's all just config
values applied to build #12345.

~~~
lucozade
I used to work at a startup where the CEO would make us do big major, random
version jumps to make the products appear more mature.

I was occasionally tasked with gently telling a client that they didn't need
to mobilise the world as the only changes to their version of the code were a
few minor bug fixes. How they laughed. Not.

I, semi-seriously, suggested that, if we didn't give formal meaning to the
versions, we should do client specific versioning: we sent them the release
notes and they could decide whether it was minor or breaking and how much
integration testing would be needed.

That way everyone could play along. Never took off.

------
rubidium
Basic idea: Spread out the release of feature functionality over many
"patches" (i.e. M.m.patch) rather than releasing all of feature set all at
once.

This is, to my experience, a pretty common way to do things. But it is a
different mentality then "a feature set has to be entirely complete and have
full functionality", which seemed to be the author's prior mentality.

~~~
jameshart
There's a lot of value in _naming_ a practice, though, no matter how common it
is. I like both the description of the approach, and the name, and if it helps
people characterize the difference between flavors of semantic versioning
philosophy then that is a good thing.

------
dustingetz
Semver versioning is expensive, it doesn't really make sense for unfunded
work. "1.0" is fake security, if you want long term support you will need to
acknowledge that out of band anyway. It's unfortunate that many package
managers push projects into semver, because then when some dependency
inevitably breaks semver semantics, far away things break - spooky action at a
distance. But dependency hell is real too. Versioning is hard.

I will be using "0.0.1-alpha.XXX" for projects with immature api, and
"0.X.Y-alpha.ZZZ" for projects with mature interface but active development
which may break the api, because i think this is compatible with semver
package managers, right? I'm okay with people having to run -alpha in
production for my small projects, i'm giving you the work for free, read the
source code or don't use it.

------
mplewis
Isn't this served by doing a pre-release? Tell people they're free to use a
pre-release, but it's not guaranteed to be stable. Once you're confident it's
a reliable version, bump it to stable.

esp-link ([https://github.com/jeelabs/esp-
link/releases](https://github.com/jeelabs/esp-link/releases)) does a great job
of this. They tell you which features are in latest'n'greatest so you can try
them if you wish.

~~~
jpollock
The decision to make a software release public is (like the version number) a
decision for the marketing and sales teams to make.

The software developer's job is to attack the features in priority order
(hopefully defined by sales revenue estimates), and make sure the software is
(reasonably) always releasable.

After that, it's a risk/reward, each new feature pulls in new bugs. Does the
increased functionality offset the cost due to upgrade and stabilization?

------
perlgeek
I tend to use YYYY.MM.COUNTER these days (at least for projects that have
frequent releases). It makes it pretty obvious how fresh or stale an installed
version is, and I don't have to argue with anybody about what a feature, a
bugfix or a backwards incompatible change is.

------
restalis
I remember the Linux kernel going from 3.X.X to 4.X.X - a change in version
that didn't had that many reasons behind it. What's the point of having a
distinction between major and minor version? For all I care it would be enough
to have two digits: "version.patch", where if you add a feature - change
version number, if you just fix something - change the patch number, that's
it!

~~~
cvburgess
The MAJOR number in semantic versioning, and many versioning schemes is used
to signify the breaking of backwards compatibility. It doesn't mean "major new
feature", think of it more as "major reworking of something you may rely on".
The MINOR is used to signify new features that won't break anything in the
process.

