Work with program version numbers
And on my machine, everything works!
From profanity programmers.
In order for programmers, testers and users of the program to understand where and what is happening, where the error occurred or when you can look at a new feature, use the program versions. The easiest way is one number, increasing by one each assembly. Sometimes this method is the best. What about other products?
My IE has version number 8.0.6001.18828, and Paint has version 6.0, but the build number is 6002.
To denote the version numbers of Microsoft Office products, use the following syntax:
aa.bbbb.cccc
* aa: Office version.
* bbbb: The version of the executable file of the program, for example Excel.exe.
* cccc: The version of the Mso.dll file.
')
But the most original thing was Donald Knut. Since version 3.0, TeX uses a distinctive version numbering system: each update adds an extra decimal digit to the version number, so that it asymptotically approaches π. This reflects the fact that the current version of TeX, 3.1415926, is very stable and only minor updates are possible (see ru.wikipedia.org/wiki/TeX ).
Forget about the whip joke. How is it more convenient? In my workshop on setting up a bactrequer, I talk about various attribute groups. There are descriptive attributes, and there are managers.
The build version is important to determine where the error was found. In this case, this is part of the description of the defect, slightly different from the description of the program section or the type of error. It is also convenient to use the number of the assembly in which the defect has been fixed (a new feature has been added). And here it is most convenient to use one single number growing from assembly to assembly.
But to manage the features and defects is convenient to use the official release number. Suppose we recruit tasks for a four-week iteration. Release 2.14 is now released, the next one will be 2.16. The fact that we transfer to the operation must have a label. Otherwise, the end user will be very difficult to communicate with us. It is sometimes convenient to make a big change / small change structure. For example, “version 2” was on php + MySQL, and version 3 would be on .Net + MSSQL. In the fourth version, we will switch from a three-tier to a four-tier architecture and finally make a thick client. And in version 5, finally, we will do logistics in addition to inventory control. Those. versions 2.x, 3.x, 4, x are big jumps, and the transition 3.12-3.14 is the release of patches, adding a little functionality, etc.
Sometimes they make three levels:
• first level - big jumps, once in 6-30 months
• second level - small jumps, once in 2-4 weeks
• third level - urgent patches on demand at any time
At the same time, a picture can be observed when a part of the team is working on version 4.0, another is preparing 3.14, and a couple of guys are preparing 3.12.1 and 3.12.2 with fast hands (the number 3.12.1 will be for the one who presses the commit). Not that this was a complete nightmare of configuration management, but also a bit of joy.
I would recommend to stop at the two-level numbering of releases. If your team serves one client (support and development of the system), then it is convenient to make the first number the number of the planned iteration, and the second the number of the patch to the product version. For the boxes will be different, but there you can get two numbers
There is another interesting practice when the versions under development have an odd number, and those that are in operation are even.
So, for example, even if version 14.0 is in operation now (or the result of the seventh four-week iteration), 15.0 is in development, but patches 14.1 and 14.2 have already been released.
The full version number in this case will look like aa.b.ccc, where:
• aa - release number
• b - patch number
• ccc - build number
And you will have something like this:
• Version 14.0.283 (release 14.0, build 283) is on the client. The next release 16.0 is scheduled to fix defects D14 and D16 and add features F10 and F11.
• The team starts work, releases 15.0.284, with F10, D14 implemented.
• But here users find a pair of defects in 14.0.283. It was decided to make D17 a patch, and D16 to postpone until better times. Patch 14.1.285 is released.
•…
• 15.0.289 and 16.0.289 are identical. The difference in the numbers is made in order to show that this is the official release.
This method of numbering is quite convenient for many cases. Perhaps it specifically does not suit your project. Most importantly, if you change something, remember that there are descriptive attributes and there are managers. You can build control on other non-version attributes. In this case, the number can be simplified. And it may be that everything is clear to everyone and the version number is simply not needed. It also happens. However, about this or in another article or at the training.
From profanity programmers.
In order for programmers, testers and users of the program to understand where and what is happening, where the error occurred or when you can look at a new feature, use the program versions. The easiest way is one number, increasing by one each assembly. Sometimes this method is the best. What about other products?
My IE has version number 8.0.6001.18828, and Paint has version 6.0, but the build number is 6002.
To denote the version numbers of Microsoft Office products, use the following syntax:
aa.bbbb.cccc
* aa: Office version.
* bbbb: The version of the executable file of the program, for example Excel.exe.
* cccc: The version of the Mso.dll file.
')
But the most original thing was Donald Knut. Since version 3.0, TeX uses a distinctive version numbering system: each update adds an extra decimal digit to the version number, so that it asymptotically approaches π. This reflects the fact that the current version of TeX, 3.1415926, is very stable and only minor updates are possible (see ru.wikipedia.org/wiki/TeX ).
Forget about the whip joke. How is it more convenient? In my workshop on setting up a bactrequer, I talk about various attribute groups. There are descriptive attributes, and there are managers.
The build version is important to determine where the error was found. In this case, this is part of the description of the defect, slightly different from the description of the program section or the type of error. It is also convenient to use the number of the assembly in which the defect has been fixed (a new feature has been added). And here it is most convenient to use one single number growing from assembly to assembly.
But to manage the features and defects is convenient to use the official release number. Suppose we recruit tasks for a four-week iteration. Release 2.14 is now released, the next one will be 2.16. The fact that we transfer to the operation must have a label. Otherwise, the end user will be very difficult to communicate with us. It is sometimes convenient to make a big change / small change structure. For example, “version 2” was on php + MySQL, and version 3 would be on .Net + MSSQL. In the fourth version, we will switch from a three-tier to a four-tier architecture and finally make a thick client. And in version 5, finally, we will do logistics in addition to inventory control. Those. versions 2.x, 3.x, 4, x are big jumps, and the transition 3.12-3.14 is the release of patches, adding a little functionality, etc.
Sometimes they make three levels:
• first level - big jumps, once in 6-30 months
• second level - small jumps, once in 2-4 weeks
• third level - urgent patches on demand at any time
At the same time, a picture can be observed when a part of the team is working on version 4.0, another is preparing 3.14, and a couple of guys are preparing 3.12.1 and 3.12.2 with fast hands (the number 3.12.1 will be for the one who presses the commit). Not that this was a complete nightmare of configuration management, but also a bit of joy.
I would recommend to stop at the two-level numbering of releases. If your team serves one client (support and development of the system), then it is convenient to make the first number the number of the planned iteration, and the second the number of the patch to the product version. For the boxes will be different, but there you can get two numbers
There is another interesting practice when the versions under development have an odd number, and those that are in operation are even.
So, for example, even if version 14.0 is in operation now (or the result of the seventh four-week iteration), 15.0 is in development, but patches 14.1 and 14.2 have already been released.
The full version number in this case will look like aa.b.ccc, where:
• aa - release number
• b - patch number
• ccc - build number
And you will have something like this:
• Version 14.0.283 (release 14.0, build 283) is on the client. The next release 16.0 is scheduled to fix defects D14 and D16 and add features F10 and F11.
• The team starts work, releases 15.0.284, with F10, D14 implemented.
• But here users find a pair of defects in 14.0.283. It was decided to make D17 a patch, and D16 to postpone until better times. Patch 14.1.285 is released.
•…
• 15.0.289 and 16.0.289 are identical. The difference in the numbers is made in order to show that this is the official release.
This method of numbering is quite convenient for many cases. Perhaps it specifically does not suit your project. Most importantly, if you change something, remember that there are descriptive attributes and there are managers. You can build control on other non-version attributes. In this case, the number can be simplified. And it may be that everything is clear to everyone and the version number is simply not needed. It also happens. However, about this or in another article or at the training.
Source: https://habr.com/ru/post/73351/
All Articles