PC SOFT

FORUMS PROFESSIONNELS
WINDEVWEBDEV et WINDEV Mobile

Accueil → WINDEV 2024 → Software Version naming conventions
Software Version naming conventions
Débuté par M. Beaven, 27 jan. 2004 06:30 - 6 réponses
Posté le 27 janvier 2004 - 06:30
Hello everyone,
I have become curious this evening regarding the version numbers of some of the software I have installed, and this curiosity has gotten to me as it relates to the software I generate with Windev.
Does anyone know of any reference or conventions for software "version" assigment? - i.e- 1.0, 2.0, etc. I have seen some vague refences in sofware licensing agreements, but was unable to find any sort of authoritative reference on the subject or guidelines regarding said version number assignment.
Is anyone aware of any such conventions in assigning software version numbers?
Thanks for any comments,
Marc
Posté le 27 janvier 2004 - 06:55
Hi Marc
I do not think there is any hard and fast rules
For naming Conventions.
Normally my numbering is
"Version Number"(I may have different Versions for Different Operating Systems)
"Build Number"(Or how many Times I have Improved/Enhanced the Product)
Microsoft probably have some guidlines on Versioning, but I never follow
Microsofts Guidlines anyway.
Keep well
Peter

Hello everyone,
I have become curious this evening regarding the version numbers of some of the software I have installed, and this curiosity has gotten to me as it relates to the software I generate with Windev.
Does anyone know of any reference or conventions for software "version" assigment? - i.e- 1.0, 2.0, etc. I have seen some vague refences in sofware licensing agreements, but was unable to find any sort of authoritative reference on the subject or guidelines regarding said version number assignment.
Is anyone aware of any such conventions in assigning software version numbers?
Thanks for any comments,
Marc
Posté le 27 janvier 2004 - 06:55
Hi Marc
I do not think there is any hard and fast rules
For naming Conventions.
Normally my numbering is
"Version Number"(I may have different Versions for Different Operating Systems)
"Build Number"(Or how many Times I have Improved/Enhanced the Product)
Microsoft probably have some guidlines on Versioning, but I never follow
Microsofts Guidlines anyway.
Keep well
Peter

Hello everyone,
I have become curious this evening regarding the version numbers of some of the software I have installed, and this curiosity has gotten to me as it relates to the software I generate with Windev.
Does anyone know of any reference or conventions for software "version" assigment? - i.e- 1.0, 2.0, etc. I have seen some vague refences in sofware licensing agreements, but was unable to find any sort of authoritative reference on the subject or guidelines regarding said version number assignment.
Is anyone aware of any such conventions in assigning software version numbers?
Thanks for any comments,
Marc
Posté le 27 janvier 2004 - 08:29
Hi Marc,
'versioning' can be pretty complicated IF a product got 'sidelines', this means, if the program in several states gets other derivative programs. The idea behind versioning is to be able to find out quickly on which 'mother'-program a certain program is based AND to be able to properly identify parts of programs to be updated, be it for error correction, be it for extension of features.
Story: You develop a program 'TheBestOne' for customer AA (= version 1.000.000). The '1' stands for main changes of the program, certainly to be paid for by customers. The first '000' stands for the 'sidelines' for which you should have a graph hanging on the wall of your office, just in case your program's sold to several dozens of customers. The second '000' stands for changes of that specific program and identifies fixed or unfixed problems, added features and so on. You could split that up into two blocks of '000' in order to separate features and bugs. Feature-adding is charged, bug fixing is free, a usual way to handle income. Its up to you to judge, whether a customers 'problem' is a 'feature' or a simple 'bug'. Borders between the two are not that distinct as one would expect. Is crashing of 'TheBestOne' at 'negative quantities in delivery notes' a simple bug or is it just a special new feature - a wish of that customer?
- So, you should have specific software (hotline management) or at least a simple Word-document telling you the general 'features and problems' in chronological sequence and whether they got added or fixed in real code. Each of them is getting a unique identifier. The identifier can be in text form too like 'Delivery notes crash on negative qty' or 'customer CC likes to have pro-forma-invoice added'. There you see the problem: not every feature to be added and not every bug applies necessarily to each package of 'TheBestOne' in the field.
- For each sideline (the 1.xxx.000's) there should be a document too. Identifying which changes had been applied at each version step and which are identified, but pending.
To overcome the complexity of the job, there is a whole industry making 'versioning'-software to help developers. Versioning software archivates versions, you can extract older versions, you can add derivatives to the archive too, you can compare versions, you can document changes to certain versions.
On the other hand, if your product is just for one customer or you sell lots of copies but have strictly decided against any sidelines, its pretty easy to find out whether a customer owns the last version or an older one. 1.018 is older than 1.021. Its always good to have documentation at hand that shows which features were added and which bugs were fixed with each version. My customers have that available online, so I force myself to keep documentation in shape.
Best regards,
Guenter

Hello everyone,
I have become curious this evening regarding the version numbers of some of the software I have installed, and this curiosity has gotten to me as it relates to the software I generate with Windev.
Does anyone know of any reference or conventions for software "version" assigment? - i.e- 1.0, 2.0, etc. I have seen some vague refences in sofware licensing agreements, but was unable to find any sort of authoritative reference on the subject or guidelines regarding said version number assignment.
Is anyone aware of any such conventions in assigning software version numbers?
Thanks for any comments,
Marc
Posté le 27 janvier 2004 - 13:02
Hello everyone,
I have become curious this evening regarding the version numbers of some of the software I have installed, and this curiosity has gotten to me as it relates to the software I generate with Windev.
Does anyone know of any reference or conventions for software "version" assigment? - i.e- 1.0, 2.0, etc. I have seen some vague refences in sofware licensing agreements, but was unable to find any sort of authoritative reference on the subject or guidelines regarding said version number assignment.
Is anyone aware of any such conventions in assigning software version numbers?
Thanks for any comments,
Marc

Hi marc,
As we still not write our doc arround it, here is an exclusively way to act with windev...
Numbring convention
V.D.M.m(rc)
V : main version of you soft
D : data analysis version (careful, must only increase by 1 at each compiled version, dev team must work around it)
M : major modification (functions or screens) = viewable updates
m : minor modifications (calculations) = unviewable updates
rc : Release candidates (unstable), temporal version for immediate unblocking updates.
D part is used to see if data modification will be necessary, should follow data model generation version. Of course dev team must increase this number only one time during each package evoltion : best way is to store a data model modification liste and play with data model included version administration.
rc part is used for extra unblocking upgrade for stopped clients.
each part increment put sub part height to 0 :
1.1.0.0 = first version (1 and datamodel = 1)
1.1.0.1 = first minor patch
1.1.1.0 = first major patch
1.1.1.0(a) = temporal patch on 1.1.1.0
1.2.0.0 = first datamodel update (with related functions...)
2.1.0.0 = main version avoluted (*)
(*) at this point we still not got, damatmodel version should be set to 1. Main problem is to find a solution for 1.x installed data migration (still under research... solutions welcome)
Note : of course complete project backups for eache version MUST be done and verified.
Nowadays, never found better tu use...
@+ R&B



rbesset.net, french windev unofficial gate
Posté le 27 janvier 2004 - 17:42
Thanks to all for the comments. I know there is no formal method for "versioning", but it is good to see some of the conventions used by developers.
-Marc
Hello everyone,
I have become curious this evening regarding the version numbers of some of the software I have installed, and this curiosity has gotten to me as it relates to the software I generate with Windev.
Does anyone know of any reference or conventions for software "version" assigment? - i.e- 1.0, 2.0, etc. I have seen some vague refences in sofware licensing agreements, but was unable to find any sort of authoritative reference on the subject or guidelines regarding said version number assignment.
Is anyone aware of any such conventions in assigning software version numbers?
Thanks for any comments,
Marc
Posté le 27 janvier 2004 - 17:42
Thanks to all for the comments. I know there is no formal method for "versioning", but it is good to see some of the conventions used by developers.
-Marc
Hello everyone,
I have become curious this evening regarding the version numbers of some of the software I have installed, and this curiosity has gotten to me as it relates to the software I generate with Windev.
Does anyone know of any reference or conventions for software "version" assigment? - i.e- 1.0, 2.0, etc. I have seen some vague refences in sofware licensing agreements, but was unable to find any sort of authoritative reference on the subject or guidelines regarding said version number assignment.
Is anyone aware of any such conventions in assigning software version numbers?
Thanks for any comments,
Marc