Each application has three versions: a program version, a file version, and the marketing version.
Given a program version number MAJOR.MINOR.BUILD.REVISION, increment the:
Additionally, any of these values may be a random number, generated whenever you compile or build your application. In some contexts, your program version will only consist of three parts... sometimes two parts... so try not to attribute too much meaning to the numbers.
Given a file version number MAJOR.MINOR.BUILD.REVISION, increment the:
Additionally, any of these values may be a random number, generated whenever you compile or build your application. In some contexts, your file version will only consist of three parts... sometimes two parts... so try not to attribute too much meaning to the numbers. Why do we need this when it is essentially the same as the program version? I dunno, man! There might be a time when your program changes without changing the file! Or your file might change without changing the program! Have you thought of that? Huh?!??
This is the most important version number. Given a marketing version number WHATEVER, change the:
If you don't have a marketing department, one can be simulated using a standard six sided die. On a roll of:
In the world of job security, there exists a blessed utopia called "dependency hell." The bigger your system grows, and the more packages you integrate into your software, the more likely you are to become irreplaceable thanks to this loveable condition.
In order to perpetuate this beautiful scheme, I propose a simple set of rules and requirements that dictate how version numbers are assigned and incremented. These rules are based on, but not necessarily limited to, pre-existing, but unfortunately not very widespread, practices in use in both closed and open-sourced software. For this system to work, you must give as little fucks as possible. Less work and job security? Score!
I call this system "Mega Super Versioning." Under this scheme, version numbers are random and arbitrary.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as per the Merriam-Webster definition of "optional".
Software using Mega Super Versioning MUST do whatever the hell it wants. However it is done, it SHOULD be incoherent.
A normal verison number MUST take the form A.B.C.D, or A.B.C, or A.B, or just A, or whatever. Each element MUST change however you'd like. Randomness is RECOMMENDED.
Once a versioned package has been released, the contents MAY be modified if you'd like. Any modifications MAY be released as a new version.
Anything may change at any time.
The way in which the version number is incremented after this release is dependent on nothing.
Build version D (a.b.c.D) MAY be changed if, you know, you feel like it. A random number is RECOMMENDED.
Revision version C (a.b.C.d) MAY be changed sometimes, too. A random number is RECOMMENDED.
Minor version B (a.B.c.d) MAY be random, or not... whatever.
Major version A (A.b.c.d) MAY be something.
A pre-release version MAY be denoted by appending or prepending some kind of identifier to your version string. It's better to just give it a regular version number though, to keep users guessing as to whether or not your application is considered "production ready".
Add some build metadata to your version string. Afterall, this is your string, so make it your own.
If you've done your versioning correctly, it SHOULD be nearly impossible to tell which version is the newest.
This is not a new or revolutionary idea. In fact, you've probably dealt with software that does this already. What we've done here is given a name to it, so it sounds more legit. It takes very little effort, and should guarantee some sort of job security, so, really, why wouldn't you use it?
Let's be honest: the development phase never ends, so, you know... whatever...
Whenever "feels" right... maybe once a year? Listen: we all your know your users are going to do QA for you, so try not to think about it too much. Whenever you feel your product is in an early beta phase, update the marketing version and release it to customers. That's been working for us!
You betchya!
I know, right?! Who wants to do that?
Ugh, supporting deprecated code is a pain, right? I find it's best to just cut it and release with the same version number. What could go wrong?
No! Of course not! Feel free to personalize your version string so it sticks out.
NO! Any sane developer should be using semantic versioning, from which this site has borrowed heavily.
The Mega Super Versioning specification is authored in jest by Bob Matcuk, inventor of nothing.