June 9th, 2013 at 5:30 PM
Nice thread.
Unlike the majority of software coders, I usually prefer to have my alpha releases semi-stable. I'll usually have a limited number of features in them, but I won't call a release "alpha" unless it at least works. My file exchange software is well beyond what most people would call a first alpha release, yet due to the huge number of bugs in the software I'm still calling it a proof-of-concept release.
I'll typically release a BETA release once everything is completed and I simply need to debug and make some final tweaks. The goal is to have the beta look like the final product is supposed to look. Obviously, especially after a first beta, many changes will need to be made, but I try to make sure that the software is complete enough prior to release that the software gives a realistic snapshot of what the final development will look like.
Unlike the majority of software coders, I usually prefer to have my alpha releases semi-stable. I'll usually have a limited number of features in them, but I won't call a release "alpha" unless it at least works. My file exchange software is well beyond what most people would call a first alpha release, yet due to the huge number of bugs in the software I'm still calling it a proof-of-concept release.
I'll typically release a BETA release once everything is completed and I simply need to debug and make some final tweaks. The goal is to have the beta look like the final product is supposed to look. Obviously, especially after a first beta, many changes will need to be made, but I try to make sure that the software is complete enough prior to release that the software gives a realistic snapshot of what the final development will look like.
