|
|
Post by jarych on Jun 30, 2019 18:50:30 GMT
Is any standard practice common for deciding when a version goes from some 0.X, to full version 1.0 ? I am guessing that version less than 1 is for something either in development with some possibly undeveloped parts or something made available for use or testing in a restricted community/set of users. Version 1 would then be intended for wider or unrestricted distribution and is more fully developed and maybe also more tested by some users. Curious of usual version numbering practices
|
|
|
|
Post by Rod on Jun 30, 2019 19:55:45 GMT
After the point usually means bug fixes or minor improvements to current functionality. Before the point usually means new functionality.
|
|
|
|
Post by jarych on Jun 30, 2019 20:05:58 GMT
The intent of the question is trying to understand version 1 or greater in contrast to version less than 1. Has any standard meaning been common for versions "less than 1"?
|
|
|
|
Post by cundo on Jun 30, 2019 22:59:25 GMT
In my case I just go creative with my numbering. Sometimes I start with a 101 version and grow up from there, ie: 102, 103 etcetera.
I don't know of any standard, and I have seen so many ways to do version numbers.
You could go like this: below 1, alpha versions, that feels OK to me.
|
|
|
|
Post by jarych on Jul 1, 2019 0:49:21 GMT
.... .... You could go like this: below 1, alpha versions, that feels OK to me. That's has become my way to think, too. My own personal practice seems to have been: 0.x, program still in development; still planning to make some corrections; still planning to add some feature or features, even if ready for a few people to test run; 1 or 1.0 or integer part greater than 1, program is finished for the current time, and maybe ready for either less restricted or unrestricted distribution. When just keeping a project to myself, I might just use date in some form or other to keep track of the different versions. |
|
|
|
Post by Stefan Pendl on Jul 7, 2019 7:02:19 GMT
Most developers follow the scheme {major}.{minor}.{bug fix}[.{build}] and leave out any part at the tail they don't need. In many projects the major release turns from zero to one, when all features are build in. - major
- the major number mostly changes when a huge amount of features has changed
- it may also change if supported operating systems change, the GUI has been revamped or other things
[li]minor[/li] - this usually changes when features are added, removed, etc.
[li]bug fix[/li] - should be obvious and changes for bug fix releases
[li]build[/li] - is increased by automatic build systems
[/ul]
In many cases the developer is free to use whatever he likes. Some of the projects are now moving to date numbering {year}.{month}[.{day}], like 2019.07, if they release monthly or less often.
|
|
