The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
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.
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...
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).
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 v126.96.36.199 but a second release today would be v188.8.131.52.
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. The non-numeric version numbers just keep the users on their toes.
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.)
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!
Congratulations! I too reach a milestone shortly (big six-oh for me) and while it's probably the dullest, dampest, most boring time of the year to have a natal anniversary, only the finest were conceived in early spring!
The best of the day is due you, sir - and many happy returns are to be hoped for.
Sent from my Amstrad PC 1640 Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
But have no skills in game design besides the concept of the game in my head.
One simple rule: It must be fun. Avoid everything that is overly complicated or repetitive, You must find the optimal spot between boredom and stress. And forget the word 'realistic'. You can make your own little reality and can make the rules as you please.
Zaf Khan wrote:
I would like to use Unity engine
You are starting at the wrong end. If you try to do everything at one, the whole thing will descend into chaos. How about taking a tip from web development and use a three tier approach?
- The 'lowest' tier is a data layer. It must not be built with or around a database, but it can be. The are many more options, like storing your data (like your map) in binary files, XML, punched paper tape, floppy disks or anything else that suits your needs. All this layer does is to store data (like for example a tile of your map) or find it for you when you ask for it.
- The middle tier is the game logic. Here is where the games rules are implemented. It uses the functions of the lower tier to fetch and store the data it needs.
- The uppermost tier is the presentation layer. It does nothing more (huge understatement!) Than take the player's inputs, call functions of the middle tier to process them and then 'present' the returned results to the player. Here you must do all the drawing and again you are totally free to use anything at your disposal, from simple console output to huge rendering engines like Unity. Build the simplest presentation layer you can at first. Console I/O is really easy, but limited and ugly. This way you can concentrate on the lower tiers, build and test them without getting bogged down with how to draw this or that. Once you have a working game, you can still write a new presentation layer with any fancy graphics you like and concentrate on doing that and nothing else.
Zaf Khan wrote:
My programming is okay
Self praise stinks. You will quickly find that you have chewed off too much. That's okay as long as you can work at one problem at a time and don't try to do everything at once. Use that three tier approach to keep your problems separated and try to keep the scope of your game small until you know that you can handle it. Better a small finished game than an eternal construction site.
How I know that? I started out on this thing[^]. The data layer (yes, I take my own medicene) can spew out solar systems in 4 billion universes, each with 4 billion galaxies, each of the galaxies having hundreds of billions of complete soloar systems with planets and moons. Talk about an insane scope. I should take a year or two off and finally finish it. Not that such a beast ever is really 'finished'.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
- First, create your data base (not database, I mean the base for all your data ), i.e. data layer
- Create a Business Layer, keep it as abstract as possible, and always keep performance in mind, so do not overengineer things.
- Maintainability of software is extremely important, but consider the drawbacks of DIP, IoC and the like, as reflection and dynamic type resolve are VERY expensive operations when it comes down to microseconds when developing a game.
- Keep those at a minimum necessary for your code to be maintainable, but don't create the holy formula for peace on earth.
Besides all of that, I would like to add one single thing:
It is not ultimately true, that you can create those layers "at will".
You need to make one important decision:
- The technology where this all will end
Means: If you plan to go the Unity path, C# is fine.
If you use other platform independant Engines, like libGdx (for Java), DeFold (based on lua language), you might find out, that your layers will not work, as libGdx and DeFold simply don't know about C#.
So, before writing a single line of code, make sure, that you will be able to use your lower layers in the engine where the presentation will take place.