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
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.
-
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
With RAD, there is little time to think (much) about the versioning. You mostly want to know whether someone is testing / using an earlier or later version when dealing with multiple "cells". So I just let Visual Studio do the counting. Just make sure all the modules in the project are using the same pattern. (AssemblyInfo.cs) [Assembly Versioning | Microsoft Docs](https://docs.microsoft.com/en-us/dotnet/framework/app-domains/assembly-versioning)
"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal
-
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
Version Class (System) | Microsoft Docs[^]. This might help. It's specific to .net but it also talks about general version parts and the meaning. We also have Semantic Versioning 2.0.0 | Semantic Versioning[^]
-
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"
PeteTheDiver wrote:
full stop was rarely used
I don't think I ever recall a dot being used as a pounds/shillings/pence separator - it was always the forward slash. My first-ever role as a contractor (1983) involved making some changes to an accounting system. I was a COBOL developer but had included in my CV that I also knew BASIC and 6502 assembly language. The recruiter idiot had decided I was a great match for a client needing an IBM assembler programmer. (After all, how different could IBM mainframe and 6502 be?) :laugh: So it was a steep learning curve, to put it mildly. What was worse was that the system predated 1971 and handled all currency in pounds/shillings/pence. At decimalisation they'd kept the three fields and stored the number of (new) pence by dividing by 12, putting the result in the shillings, and the remainder in the pence. (e.g. 50p was represented as 4/2). Thankfully it was only a six-month contract but I think that's when the grey hair started...
-
Version Class (System) | Microsoft Docs[^]. This might help. It's specific to .net but it also talks about general version parts and the meaning. We also have Semantic Versioning 2.0.0 | Semantic Versioning[^]
I use Microsoft's versioning too; not their "do as I say", but their "do as I do". This gives the sequence: 1, 2, 3, 3.1, 3.11, 95, 98, 98SE, ME, 2000, XP, Vista, 7, 8, 8.1, 10. Then the sequence ends. It's clear, unambiguous, intuitive. :-D The non-numeric version numbers just keep the users on their toes.
-
I use Microsoft's versioning too; not their "do as I say", but their "do as I do". This gives the sequence: 1, 2, 3, 3.1, 3.11, 95, 98, 98SE, ME, 2000, XP, Vista, 7, 8, 8.1, 10. Then the sequence ends. It's clear, unambiguous, intuitive. :-D The non-numeric version numbers just keep the users on their toes.
Made me laugh! Thank you :laugh:
|| You know nothing, Jon Snow. || My Android Label (mbar Software) || My Android Apps in Play Store
-
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
-
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
Mike Barthold wrote:
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
Took me a bit to figure that out. But basically there is a third variation. Each 'number' is a decimal. So 2.1 is followed by 2.2, etc and then up to 2.10, 2.11, etc. Other than that version is a policy decision that the releasing entity sticks to. Thus as at least one other poster suggested the following is a valid policy. Although the last tends to be overkill. ...
Mike Barthold wrote:
2.1 followed by hotfix 2.11, 2.12, etc Next minor release after 2.1 can be 2.2 (= 2.20)
Sounds like a bad policy decision to me. Hotfix and minor are release decisions. But that shouldn't impact versioning. The policy should define what how a release decision is made but the contents of the release define what happens to the version number. And a hotfix would normally be a minor revision because it is in fact a release and because is is a fix (just as presumably there are other fixes in any release.)
-
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
Having don this a few ways: 2.1 2.01 2.00.1 Major.Minor[.BugFix] was the meaning. And we shifted to a mandatory 2 digits for Minor (2.01, 2.02, Counting up). Where the Least increment was for normal weekly/daily releases. 2.50 would be a pretty sizable JUMP, and we try NOT to get to 3.00 naturally (99 updates). But we will GAP the numbers to imply certain milestones. The BugFix concept was added so our AutoUpdater could IGNORE them. We could identify them and let users choose to update to them with a strict warning. The average user would never get the message, and never get that version. (Beta Channel users would!) The instant you add a second decimal... You realize you are not dealing with a number, but a string!