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.
Progressive Versioning
11–16 of 16 posts
Re: Progressive Versioning
#12Version 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…
> 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 w…
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.
Re: Progressive Versioning
#13Isn'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?
Re: Progressive Versioning
#14Version 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…
> 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.
Re: Progressive Versioning
#15Version 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…
> 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 w…
Sublime text follows this approach:
However Semver is useful for dependency managing.
Re: Progressive Versioning
#16Version 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…
> 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…
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.