|
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;
|
|
|
|
|
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.
|
|
|
|
|
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...
|
|
|
|
|
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.
|
|
|
|
|
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 v19.2.21.0 but a second release today would be v19.2.21.1.
|
|
|
|
|
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
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
|
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.
|
|
|
|
|
Made me laugh! Thank you 
|
|
|
|
|
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.
<major version="">.<minor version="">.<build number="">.<revision>
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.)
|
|
|
|
|
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!
|
|
|
|
|
Anxious western sweets (8)
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
38. Be aware of sounding negative (4)
|
|
|
|
|
|
ya 
modified 20-Feb-19 0:51am.
|
|
|
|
|
Nice one!
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!
|
|
|
|
|
|
Happy 
|
|
|
|
|
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.
![Beer | [beer]](https://www.codeproject.com/script/Forums/Images/beer.gif) ![Jig | [Dance]](https://www.codeproject.com/script/Forums/Images/jig.gif) ![Badger | [badger,badger,badger,badger...]](https://www.codeproject.com/script/Forums/Images/badger.gif) ![Sunshine | [little ray of sunshine]](https://www.codeproject.com/script/Forums/Images/sunshine.gif)
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!
|
|
|
|
|
|
I'm really interested in developing a game.
I want it to be like age of empires style.
looking like 3D
But actually 2D but just not a birds eye view (more 3d looking)
I would like to use Unity engine
But have no skills in game design besides the concept of the game in my head.
I would like to start with a game map and have a view port so as to be able to see only a portion of the map which scrolls as player moves left/right.
Once I get to that stage then I would like to add the sprites.
How do I go about creating map in Unity?
I would ideally like to take a country map and have it 3 dimensions x,y and z but only z where there hills/mountains like The Alps in Switzerland for example
Please can any members advise me the best route to take.
My programming is okay, but about graphics and game dev I know nothing
but am willing to learn each step as it comes along.
I read some of the articles on the site and they kind of blew me away.
But I'm sure if I go one step at a time then I can do it.
So how do I go about creating a terrain map in Unity with contours?
Thank You
|
|
|
|
|
Zaf Khan wrote: 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.
modified 20-Feb-19 5:26am.
|
|
|
|
|
@ Code Wraith
Hiya and Thank you for all the advice.
I'm currently working on my data layer and building the map, it's far from finished and I do not intend to start coding straight away.
I will worry about coding when I get to it, but have taken the step of investing in a few decent books.
Cost me a pretty packet but what the hell, it's only money and you cannot take it with you lol...
|
|
|
|
|
While I agree to 99% with CodeWraith, by
- 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.
modified 20-Feb-19 3:34am.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
