Are Software versions a decimal?
-
What I mean with this cryptic question: Do you treat the first part of software versioning (i.e. "2.4") like a decimal number or do you simply "count up"? If treated as decimal, it would mean, that "2.4" is equal to "2.40" (like a decimal number is equal), if you count up, not. Decimal version flow: 2.1 followed by hotfix 2.11, 2.12, etc Next minor release after 2.1 can be 2.2 (= 2.20) Count up: 2.1 followed by 2.2, ... ... 2.8, 2.9, 2.10, 2.11 and so on I hope I could explain, what I mean. How do software versions evolve in your minds?
|| You know nothing, Jon Snow. || My Android Label (mbar Software) || My Android Apps in Play Store
Count up... In cases that my code is an extension for 3rd party I use 4 parts - 2 for the version of the targeted 3rd part and 2 for mine... but still count up in mine...
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
-
What I mean with this cryptic question: Do you treat the first part of software versioning (i.e. "2.4") like a decimal number or do you simply "count up"? If treated as decimal, it would mean, that "2.4" is equal to "2.40" (like a decimal number is equal), if you count up, not. Decimal version flow: 2.1 followed by hotfix 2.11, 2.12, etc Next minor release after 2.1 can be 2.2 (= 2.20) Count up: 2.1 followed by 2.2, ... ... 2.8, 2.9, 2.10, 2.11 and so on I hope I could explain, what I mean. How do software versions evolve in your minds?
|| You know nothing, Jon Snow. || My Android Label (mbar Software) || My Android Apps in Play Store
-
What I mean with this cryptic question: Do you treat the first part of software versioning (i.e. "2.4") like a decimal number or do you simply "count up"? If treated as decimal, it would mean, that "2.4" is equal to "2.40" (like a decimal number is equal), if you count up, not. Decimal version flow: 2.1 followed by hotfix 2.11, 2.12, etc Next minor release after 2.1 can be 2.2 (= 2.20) Count up: 2.1 followed by 2.2, ... ... 2.8, 2.9, 2.10, 2.11 and so on I hope I could explain, what I mean. How do software versions evolve in your minds?
|| You know nothing, Jon Snow. || My Android Label (mbar Software) || My Android Apps in Play Store
For the major number you count up - version 9 is followed by 10 followed by 11. 11 is not version 1 with a hotfix. Why would you have different semantics for the major and the minor version number? Most tools / standards are prepared for handling up to 4 levels, so 2.1 followed by a hotfix is 2.1.1 rather than 2.11. (I have been annoyed at MS even since 2.11, which really was 2.1.1.) You will read 2.11 as "two eleven", not as "two one one", so it should have the semantics of "eleven" as well. I am even more annoyed by developers who make a version 5.6.14 which replaces the file format of 5.6.13 with a new one. Format or interface changes should bump the major version number. Extensions and additions should bump the minor version number (or possibly the major, if there are other significant changes), but it should be 100% backwards compatible. Micro versions should be bug fixes only, no functional extensions or changes. Version numbers are for the users! The developers use build numbers/timestamps. Ask yourself what information the typical user would hope to get from the version number. The main rule of major = changes, minor = additions, micro = fixes and improvements is simple and easy to understand. It is gaining popularity, at least in the principles stated - having the developers and system builders live by the principles is a lot harder, but it even the cat herd is slowly learning to behave :-)
-
-
For the major number you count up - version 9 is followed by 10 followed by 11. 11 is not version 1 with a hotfix. Why would you have different semantics for the major and the minor version number? Most tools / standards are prepared for handling up to 4 levels, so 2.1 followed by a hotfix is 2.1.1 rather than 2.11. (I have been annoyed at MS even since 2.11, which really was 2.1.1.) You will read 2.11 as "two eleven", not as "two one one", so it should have the semantics of "eleven" as well. I am even more annoyed by developers who make a version 5.6.14 which replaces the file format of 5.6.13 with a new one. Format or interface changes should bump the major version number. Extensions and additions should bump the minor version number (or possibly the major, if there are other significant changes), but it should be 100% backwards compatible. Micro versions should be bug fixes only, no functional extensions or changes. Version numbers are for the users! The developers use build numbers/timestamps. Ask yourself what information the typical user would hope to get from the version number. The main rule of major = changes, minor = additions, micro = fixes and improvements is simple and easy to understand. It is gaining popularity, at least in the principles stated - having the developers and system builders live by the principles is a lot harder, but it even the cat herd is slowly learning to behave :-)
I just wanted to collect your oppinions, because I heard both versions in the past. Some kind of reality check, not more :-)
|| You know nothing, Jon Snow. || My Android Label (mbar Software) || My Android Apps in Play Store
-
With more than two levels it becomes hard to argue for the dot being a decimal point. Unless you are British and old enough to long back to the shillings.
Member 7989122 wrote:
With more than two levels it becomes hard to argue for the dot being a decimal point.
Now you are just assuming all dots to be decimal. May be there is a dot who feels like 3. You cannot call it dot or point or decimal. That is so rude.
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[^]
-
What I mean with this cryptic question: Do you treat the first part of software versioning (i.e. "2.4") like a decimal number or do you simply "count up"? If treated as decimal, it would mean, that "2.4" is equal to "2.40" (like a decimal number is equal), if you count up, not. Decimal version flow: 2.1 followed by hotfix 2.11, 2.12, etc Next minor release after 2.1 can be 2.2 (= 2.20) Count up: 2.1 followed by 2.2, ... ... 2.8, 2.9, 2.10, 2.11 and so on I hope I could explain, what I mean. How do software versions evolve in your minds?
|| You know nothing, Jon Snow. || My Android Label (mbar Software) || My Android Apps in Play Store
Not a number. I remember when the D language was still being tested by a few people and Walter asked us whether or not it would be confusing to go from
0.99to0.100-- nope, not confusing. -
What I mean with this cryptic question: Do you treat the first part of software versioning (i.e. "2.4") like a decimal number or do you simply "count up"? If treated as decimal, it would mean, that "2.4" is equal to "2.40" (like a decimal number is equal), if you count up, not. Decimal version flow: 2.1 followed by hotfix 2.11, 2.12, etc Next minor release after 2.1 can be 2.2 (= 2.20) Count up: 2.1 followed by 2.2, ... ... 2.8, 2.9, 2.10, 2.11 and so on I hope I could explain, what I mean. How do software versions evolve in your minds?
|| You know nothing, Jon Snow. || My Android Label (mbar Software) || My Android Apps in Play Store
Definitely count up for each part. These are not decimal numbers. My version numbers are always major.minor.build. Major versions are reserved for either complete rewrites or major feature packs. Minor versions are for feature changes and bug fix packs. The build number is rather obvious but also doubles as a hotfix ID if needed. Every time the major version changes, the minor version and build numbers get reset to 0.
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave Kreskowiak -
What I mean with this cryptic question: Do you treat the first part of software versioning (i.e. "2.4") like a decimal number or do you simply "count up"? If treated as decimal, it would mean, that "2.4" is equal to "2.40" (like a decimal number is equal), if you count up, not. Decimal version flow: 2.1 followed by hotfix 2.11, 2.12, etc Next minor release after 2.1 can be 2.2 (= 2.20) Count up: 2.1 followed by 2.2, ... ... 2.8, 2.9, 2.10, 2.11 and so on I hope I could explain, what I mean. How do software versions evolve in your minds?
|| You know nothing, Jon Snow. || My Android Label (mbar Software) || My Android Apps in Play Store
Ours are m.n.bbbb, where m is the major version, n the minor version, and bbbb is the build number. Each m.n value denotes a significant release of the product. Oddly, each specific m.n has it's own range of build numbers. The ranges do not intersect. For example, product 1.1 will have build numbers 1000-1499, while product 1.2 will have build numbers 1500-2499. This was required to make the "document control" people (who manage ECO's[^]) happy for some inexplicable reason. One of the minor annoyances working for a company where engineering management is all hardware engineers and all processes are hardware-oriented, whether it makes sense or not.
Software Zen:
delete this; -
Definitely count up for each part. These are not decimal numbers. My version numbers are always major.minor.build. Major versions are reserved for either complete rewrites or major feature packs. Minor versions are for feature changes and bug fix packs. The build number is rather obvious but also doubles as a hotfix ID if needed. Every time the major version changes, the minor version and build numbers get reset to 0.
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave KreskowiakEvery time the major version changes, the minor version and build numbers get reset to 0.
Build number to zero, really? Minor to zero, yes of course, but the build number is (in our case) a unique, ever-growing id right from the build server, which can not be manipulated and currently is in the mid-thousands
|| You know nothing, Jon Snow. || My Android Label (mbar Software) || My Android Apps in Play Store
-
What I mean with this cryptic question: Do you treat the first part of software versioning (i.e. "2.4") like a decimal number or do you simply "count up"? If treated as decimal, it would mean, that "2.4" is equal to "2.40" (like a decimal number is equal), if you count up, not. Decimal version flow: 2.1 followed by hotfix 2.11, 2.12, etc Next minor release after 2.1 can be 2.2 (= 2.20) Count up: 2.1 followed by 2.2, ... ... 2.8, 2.9, 2.10, 2.11 and so on I hope I could explain, what I mean. How do software versions evolve in your minds?
|| You know nothing, Jon Snow. || My Android Label (mbar Software) || My Android Apps in Play Store
I personally treat them as token-separatet number sets. Major[dot]Minor. Granted, among the reasons is my fear of comparing floats and version numbers have to be frequently compared.
-
Every time the major version changes, the minor version and build numbers get reset to 0.
Build number to zero, really? Minor to zero, yes of course, but the build number is (in our case) a unique, ever-growing id right from the build server, which can not be manipulated and currently is in the mid-thousands
|| You know nothing, Jon Snow. || My Android Label (mbar Software) || My Android Apps in Play Store
Build managers frequently count the number of executions of a given build project, assigning each build a number from a dense series local to that project. If this is what you refer to as the build number, and you for each major release define a new build project, zeroing the build number comes automatically. The global build number carries very litte information about your project. Any other build project, unrelated to yours, will modify it. The difference between two global build numbers does not tell if they span one or a dozen builds of your project. The project local number tells if the older build was the last before this one, three versions back, ten versions back.
-
What I mean with this cryptic question: Do you treat the first part of software versioning (i.e. "2.4") like a decimal number or do you simply "count up"? If treated as decimal, it would mean, that "2.4" is equal to "2.40" (like a decimal number is equal), if you count up, not. Decimal version flow: 2.1 followed by hotfix 2.11, 2.12, etc Next minor release after 2.1 can be 2.2 (= 2.20) Count up: 2.1 followed by 2.2, ... ... 2.8, 2.9, 2.10, 2.11 and so on I hope I could explain, what I mean. How do software versions evolve in your minds?
|| You know nothing, Jon Snow. || My Android Label (mbar Software) || My Android Apps in Play Store
I thought some one would have mentioned it by now. It's called Semantic Versioning and you can read the spec at Semantic Versioning 2.0.0 | Semantic Versioning[^] The About section at the bottom states: "The Semantic Versioning specification is authored by Tom Preston-Werner, inventor of Gravatars and cofounder of GitHub." If it's good enough for him...
-
Build managers frequently count the number of executions of a given build project, assigning each build a number from a dense series local to that project. If this is what you refer to as the build number, and you for each major release define a new build project, zeroing the build number comes automatically. The global build number carries very litte information about your project. Any other build project, unrelated to yours, will modify it. The difference between two global build numbers does not tell if they span one or a dozen builds of your project. The project local number tells if the older build was the last before this one, three versions back, ten versions back.
Yes, a new build project resets, thats true. Our setup is that the scope never changes. scope is meant in terms of "visual studio solution" or "android studio project". Each app has one and only one build project on the build server. Spawned over branches, release channel, alpha channel, all that stuff. So each "channel" does not have continuous build numbers. We do this for the app/play stores as they want unique numbers and we just use the build number from the build server as apk version. only exception is the nightly full-build-test-CI build. those will never see light of day outside the testing environment. these builds have their own build number. alpha and release share a build number, and each build gets tagged with its channel name. so we have, for instance, 5270-77 are alpha and 3 days later the 5278 is the release. the builds are tagged on the build server and we can run reports on a per-channel basis to see which builds we have. each channel has different retention times, how long artifacts are kept before they get deleted. nightly gets purged every day (it purges before the next starts), if there is not a freezing tag set, alpha stays for 10 days, release forever. we can set freezing tags to prevent specific artifacts from being deleted, if they need closer investigation in case of problems/errors/failed tests. but all-in-all we just use that auto-generated number to keep the artifacts unique. we don't have so many rules in place and nobody is telling us how and what we build. we are a small company (<50 ppl) and this is very good :-)
|| You know nothing, Jon Snow. || My Android Label (mbar Software) || My Android Apps in Play Store
-
With more than two levels it becomes hard to argue for the dot being a decimal point. Unless you are British and old enough to long back to the shillings.
It was never a decimal point in the days of shillings, it was a separator the same as in software versions. Obvious when you think it through, definition of decimal is "relating to or denoting a system of numbers and arithmetic based on the number ten, tenth parts, and powers of ten", there were 20 shillings in a pound and 12 pence in a shilling so no multiples of ten. And even in the days of shillings the full stop was rarely used in writing down currency (at least in my experience), for instance two pounds, five shillings and six pence would normally be written "£2 5/6"
-
What I mean with this cryptic question: Do you treat the first part of software versioning (i.e. "2.4") like a decimal number or do you simply "count up"? If treated as decimal, it would mean, that "2.4" is equal to "2.40" (like a decimal number is equal), if you count up, not. Decimal version flow: 2.1 followed by hotfix 2.11, 2.12, etc Next minor release after 2.1 can be 2.2 (= 2.20) Count up: 2.1 followed by 2.2, ... ... 2.8, 2.9, 2.10, 2.11 and so on I hope I could explain, what I mean. How do software versions evolve in your minds?
|| You know nothing, Jon Snow. || My Android Label (mbar Software) || My Android Apps in Play Store
Not decimals. Per your example, 2.4 is the fourth revision. 2.40 is the fortieth revision (1 more than 39) For retail software, version numbers are always a political decision driven by marketing. Below can be used for in house software: You can use version numbers to represent the branches. 10.0, 10.1, 10.2, etc. are different labels along the 10 "main" branch. 10.1.x would be a support build on a separate branch that is initialized from the 10.1 label. 11.0 would indicate that all 10 changes have been re-integrated and resolved and time for a fresh start.
-
What I mean with this cryptic question: Do you treat the first part of software versioning (i.e. "2.4") like a decimal number or do you simply "count up"? If treated as decimal, it would mean, that "2.4" is equal to "2.40" (like a decimal number is equal), if you count up, not. Decimal version flow: 2.1 followed by hotfix 2.11, 2.12, etc Next minor release after 2.1 can be 2.2 (= 2.20) Count up: 2.1 followed by 2.2, ... ... 2.8, 2.9, 2.10, 2.11 and so on I hope I could explain, what I mean. How do software versions evolve in your minds?
|| You know nothing, Jon Snow. || My Android Label (mbar Software) || My Android Apps in Play Store
If I understand your question right, here's what I've been taught: it's best to think of them in the "count up" way. Each piece is a different part: majorVersion.minorVersion (some include another dot for bugfixVersion or some such. I think I've seen up to four parts.) How you determine whether a release is "major" or "minor" (and thus which part you change) is up to you. Something you might consider major (rewrite data access layer) is not to your clients; they don't see any changes. Something you might consider minor, might be major to your clients (re-styling the site so it totally looks different, even though nothing changed under the hood). One thing to keep in mind: once you've decided a release increments majorVersion, minorVersion resets to 0 (i.e., we're starting out on the 3rd big release. There will undoubtedly be smaller releases which then push it to 3.1, 3.2, etc, etc).
-
Every time the major version changes, the minor version and build numbers get reset to 0.
Build number to zero, really? Minor to zero, yes of course, but the build number is (in our case) a unique, ever-growing id right from the build server, which can not be manipulated and currently is in the mid-thousands
|| You know nothing, Jon Snow. || My Android Label (mbar Software) || My Android Apps in Play Store
I knew I was going to get a comment on that. Yeah, I reset the build number for the major version changes. The major versions are the new base version upon which everything else is built. I don't change the major version for, say, adding a pack of 5 smaller features. I change it for complete rewrites, like if I'm taking over a badly written project, or if it's a large pack of sweeping changes across most of the app, or a large pack of major feature additions, usually something that either completely changes the look and feel of the app or breaks backwards compatibility, if that's on the table, or I rewrite to use a more modern technology stack. I really don't change the major number very often. My minor versions usually get into the teens or twenties before I go for a major version change.
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave Kreskowiak -
It was never a decimal point in the days of shillings, it was a separator the same as in software versions. Obvious when you think it through, definition of decimal is "relating to or denoting a system of numbers and arithmetic based on the number ten, tenth parts, and powers of ten", there were 20 shillings in a pound and 12 pence in a shilling so no multiples of ten. And even in the days of shillings the full stop was rarely used in writing down currency (at least in my experience), for instance two pounds, five shillings and six pence would normally be written "£2 5/6"
-
What I mean with this cryptic question: Do you treat the first part of software versioning (i.e. "2.4") like a decimal number or do you simply "count up"? If treated as decimal, it would mean, that "2.4" is equal to "2.40" (like a decimal number is equal), if you count up, not. Decimal version flow: 2.1 followed by hotfix 2.11, 2.12, etc Next minor release after 2.1 can be 2.2 (= 2.20) Count up: 2.1 followed by 2.2, ... ... 2.8, 2.9, 2.10, 2.11 and so on I hope I could explain, what I mean. How do software versions evolve in your minds?
|| You know nothing, Jon Snow. || My Android Label (mbar Software) || My Android Apps in Play Store
Apparently I am an odd-ball when it comes to using version #s. Our app is comprised of a single EXE "shell" with all the functionality in individual DLLs. Not all DLLs get updated in every release. I use a version numbering system "YY.MM.DD.XX" where YY.MM.DD is the date of the DLL's release. XX is normally "0" but if we had to do a revision of the DLLs within the same date we'd increment that value. So a DLL released today would be v19.2.21.0 but a second release today would be v19.2.21.1.
