Progressive Versioning | Hacker News Reader

Progressive Versioning

allinthehead.com

39 pointstimblair15 comments

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.

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

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.

Sublime text follows this approach:

http://www.sublimetext.com/3

However Semver is useful for dependency managing.

> Version numbers are for marketing and legal.

> Software engineers should only care about the information required to create a reproducible build.

You are over generalizing. While this may be true for your company/project, it is not universally true. Version numbers are used for far more than that on many open source projects. Semantic versioning is important for some dependency management tools.

On my project, our versioning is only for internal use. We use something similar to progressive versioning, but our 'progress' builds are deployed only to our staging environment for dogfooding, review and approval. Once we believe the changes are stable we deploy a new minor version. When we need to work on larger change sets that could block this process, we increment the major version and continue development and review in parallel. Using a single build number would provide us the same ability to identify what code is on what server, but it would lack the additional contextual information about where that build fits into our development process.

I would argue that even open source projects have marketing, and external requirements go through that filter. A developer changing their version number from 0.999 to 1.0 is a marketing decision. There's no real technical reason for it, it is a signal to the market - therefore marketing.

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.

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.

In case of mobile Apps, getting people to upgrade frequently is hard. I really like the approach softwares like GitHub for Windows have in checking for updates on every run and somehow forcing continuous upgrades, but it isn't suitable for non-technical audience. "The Big Reveal" seems more interesting to the App users who usually want visible improvements in exchange of their upgrade "effort", or they will become less intrigued to update to later releases.

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.

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) does a great job of this. They tell you which features are in latest'n'greatest so you can try them if you wish.

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?

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.

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!

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.

Reply on news.ycombinator.com