Menu
I generally agree that major versions of a program should be 1.0, 2.0, ... and significant updates should be: 1.1, 1.2, ..., and that bug fixes should be at the third level: 1.0.1, 1.0.2, ... 1.0.156 (if you've been plagued by that many bug-fix releases between versions).
But now I want to release my first Beta that will be one of a series of Betas leading towards the release of version 1.0.
Specifically, it doesn't make sense to me, to number my Beta releases greater than the number I am developing to, e.g. 1.0.1 up to 1.0.15 (if I have 15 beta releases) and then follow it with 1.0.
But using numbers less than 1.0 seems awkward, e.g. 0.9.1 ... 0.9.15 and will cause confusion if I start using 1.9.1 ... 1.9.15 as the Betas for version 2.0.
How to do version numbers?
Just for information, after your help and great links with more info, this is what I decided on.
I've been going 0.7, 0.8, 0.9, 0.91 ... up to 0.98 for my alpha versions.
I know I can do 1.0 beta 1, which is the "standard" way. But taking everything into account, I'm going to go with: 0.99 beta 1, 0.99 beta 2 ... before I get to my 1.0 release.
If I do a pre-release of my 2.0 version, I'll probably then follow the pattern and call it 1.99 beta 1, 1.99 beta 2, etc.
Hopefully this question and the answers will help you decide on your scheme.
565
Beta apps are newer and more experimental versions of apps that are already released. Early access and beta apps may be less stable than most apps. For example, the app might crash or some features might not work properly. Some apps limit how many users can join early access and beta programs.
The beta version of an application is that version which is not ready for release and can be changed after the feedback from the users. Beta version comes after alpha version. It is typically visible to a limited number of users for testing purpose. For Example: Beta version of Whatsapp, beta version of fb etc.
A pre-release of software that is given out to a large group of users to try under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as a result.
View devices to find the device you want to switch and click Opt out. Your device will receive an update within 24 hours that will wipe all user data and install the latest stable public version of Android. Once you install the public update, your device is ready to enroll in another beta program.
I think you should seperate out your version numbering from the status of the release.
Betas should always have "beta" after the version. Users should not have to reverse engineer your numbering scheme to determine the stability of the release.
So leading up to version 1.0 you should have 1.0 beta 1, 1.0 beta 2 etc. That gives users a clearer idea of what major release a beta is leading towards and avoids confusion with any maintainance releases you might put out in the meantime.
The important thing is that you need to distiguish between a bugfix release (which should increase stability) and a beta (which may decrease stability).
195
If you're using an old version of Semantic Versioning, (from before 2011-03-27), this section is relevant:
A special version number MAY be denoted by appending an arbitrary string immediately following the patch version. The string MUST be comprised of only alphanumerics plus dash [0-9A-Za-z-] and MUST begin with an alpha character [A-Za-z]. Special versions satisfy but have a lower precedence than the associated normal version. Precedence SHOULD be determined by lexicographic ASCII sort order. For instance: 1.0.0beta1 < 1.0.0beta2 < 1.0.0.
26
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
