|
at least imho the elements should be controlled by:
[Marketing].[Development].[SourceControl].[BuildServer]
|
|
|
|
|
Since we sell customized platforms based on a common root (entirely self built) it's the only one that makes sense.
* CALL APOGEE, SAY AARDWOLF
* GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
* Never pay more than 20 bucks for a computer game.
* I'm a puny punmaker.
|
|
|
|
|
When we went to a Jenkins build for our code base, we took the Major.Minor.Build.Revision and coupled that with the date form. So now when we build the version is Year.Month.Day.Minute_of_Day. If we build multiple times in a day each build has it's own version and we can tell at a glance which is the latest.
|
|
|
|
|
This is how we do it too. YY.MM.DD.XX where XX is just a revision number within the date. Usually it's a zero, but if we had to do any patches of a DLL we'll increase XX by 1 each time.
|
|
|
|
|
X.Y.Z, where:
Z increments every time we deploy.
Y is always equal to zero.
X Changes for all related projects every time there's a change of direction in the project, change of product manager, change of vendor, etc.
|
|
|
|
|
Have used numerous systems over the years but now rely on simply.
string title = "MPdir.exe by electriac 2017.08.20";
this.Text = title; // Now I can use the "title with version number" to anywhere.
New versions zipped and posted to Google Drive with email notification to registered users
|
|
|
|
|
I like the YYYY.MM.DD also. The release date is an important aspect of software.
The actual date shows when versions were released and what Operating Systems / Database systems, were around then. I work in the IT field and it seems like more software companies are going with the date instead of something like "release 10 service pack 2 update 4 patch 3".
It's also easier to administrate with dates. If we have some 2010-11-08 version of some security software then we should probably upgrade asap. If we have version 10.4 of something then we would need to go look it up how old it is.
Also products can be more aligned. A system with Windows server ver 6.2 with SQL Server 10 and some driver of version 2.1 with some software of 4.0 is not really useful. Windows 2008 with SQL Server 2008 and a driver of 2006-10-01 and a software version of 2013-10-12 is much better. (in my option)
|
|
|
|
|
For the last 20 years it's been Major.Minor.Revision. The only logic for changing is that Revisions never get higher than 10 and Minors never get higher than 5. The version number(s) get(s) set manually on 2 core applications, but automatically on anything else.
An internal version number is generated as (1M * Major) + (1K * Minor) + Revision. This number is used to determine which (or if any) database updates or schema changes are required. If required, the database version is then updated accordingly.
When one of the core applications was first released over 18 years ago, management decided that we should start with version 5.2.1. 
"Go forth into the source" - Neal Morse
|
|
|
|
|
Tip: in C# you can use the Version statement to compare versions.
|
|
|
|
|
"When one of the core applications ..."
The DEV team motto at one retail software shop where I worked was:
"The version number of a release is a political decision."
As long as the number increases, just do whatever marketing says.
|
|
|
|
|
... Major.Minor.Build but tend to work with whatever I inherit. The joys of contracting
|
|
|
|
|
Although I'll ofttimes use something like 2.0.3, which looks good to onlookers, the reality is, I sort of make-it-up as I go along. As in the subject, who's to say.
Bear in mind that my 'shop' is not a software shop - we make the software to run the company and not to sell. One of my most used (10k-15K hits/day, all internal use) is being revamped (because I felt like it). I decided to use I I, thereby implying it's version two. It certainly is going to improve over the original - new schema under the hood; probably much less overhead internally, easier to teach. The old works fine - this one's extensible without adding code - I'm just in the mood.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
For Android Apps, there are 2 version numbers. The "Play Store version code" which must be an increasing integer value for each push to the store (enforced by google) and a user visible version number.
Handled quite simple, the play store version is the Bamboo Build# so I never need to care about that one. Could as well be the revision# from source control if you use svn-like cvs.
The user visible version is kept in a format similar to major.minor.build but sometimes customized, means:
1.4.1459 is valid, but as google allows customizing of this string, while in internal beta testing it sometimes looks like
"1.4.1459 beta 2"
|
|
|
|
|
I guess that's the more important question. What's the use of having two different version when they are showing the same version number?
I use a script to replace the 4th place with the Jenkins build number. The other places are handled manually.
|
|
|
|
|
I get the build# out of subversion (as the # of times I committed the code..) The major and minor version are set in the CMake script that generates my project files.
John
|
|
|
|
|
Which is included in the project as an embedded resource, and which can be viewed via the "app information" / "Help ... About" form.
I also maintain a TODO text file which is also included, but that's harder for users to see.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
saying "here's the latest..."
|
|
|
|
|
almost same here
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
