Thread

I see a lot of people posting their first version as beta release. I’m currently working on 0.8 version of the validate library and i still consider it alpha. The same with release candidates, what makes them different from a beta release?

In my view there are three release groups: alpha, beta and stable. Alpha is when features are added and it isn’t fully tested and documented. Beta means no more feature adding, but there still could be bugs and performance bottleneck in the code. Stable means fully documented, bugfree, optimal performance and the features should work as documented.

I think early beta and release candidate versions are just marketing inventions for people who want ‘bleeding edge’ software.

What do you guys and girls think?

I personally join your point of view.

You are right. So called web 2:0 changed “beta” meaning so now it’s not considered as a real beta.

I blame flickr, for eveything. for this misuse of beta, for the death of the dinosaurs, and for not knowing where my car keys were this morning.

Sorry, the car key thing was my fault.

Personally, I’ve never released an alpha.  I agree with you, though, on your use of terminology.  I just don’t release something until it is ready for beta at least. 

Here’s my definition of Release Candidate: “We feel this is a candidate to be released, because we’ve tested it and don’t know where the bugs are, but I’m sure they abound.  Therefore, test it, find the bugs for us, and help us fix them.”

Yes, it’s the same as beta.  The key difference being “marketing terminology.”  People know for sure beta is buggy.  Coming up with a new name for it, putting the word “release” in the name just makes it sound better, and more people will test it.  If you say it’s beta, you will get a smaller number to test it.  Don’t know why, it’s just a statistic.  (My definition of statistic is “I think this is right, but there are no real numbers to prove or disprove it, so I’ll say this and no one will know the difference.”  Another marketing word to make you like what I’m saying here.)

Daniel i can understand your point of view but i think as a developer in a developer community alpha releases are important because the evolution of the product is clearer. You go from concept code to workable code. The quicker other developers give you feedback the easier it is to make changes.

If i see something i find appealing i start using it even if it’s alpha. My first time i used jQuery it didn’t had a version number.

As a developer you are supposed to check things out for yourself. If you rely on marketing you can get stuck working with windows ME.

Excellent point xwero.  I’ve never really taken an opportunity for development within a developer community before.  That will probably change as soon as I’ve gotten a bit more experience with CI under my belt. 

Currently I have a set of developers that I work with that are more “in house” so to speak.  Therefore, the feedback and code sharing is in a more private setting in my particular situation until I’m ready to go beta. 

Now that I’ve found CI and the CI community I am definitely more likely to give an alpha release for the feedback. I’ve never really found a community that was as helpful before.

Web 2.0 ruined it.
Alpha is the code they only see.
Beta is when they release it to the public, but now they have excuse for bugs and missing features.
4 years later they finally remove the beta tag.

I totally go alpha… InkType is on a 9 step process until it officially makes it to beta.  Right now it’s at Pluto (headed toward the sun) and Neptune will be out this weekend (at least I’m planning on that).  I follow the ‘release early, release often’ philosophy, so I certainly didn’t want to wait until InkType was in beta to release and I’m absolutely not going to call it beta at this point.

I sort of agree, especially in InkType’s case, where the software was reasonably stable, but in some cases, alpha releases are often extremely un-featured and buggy.

I think it depends on the developer…

i take codeExtinguisher in a very natural version progression. At this point, i’m close to discarding the classic concrete “versions” (i.e. 1.0, 2.0, 3.0) and just go by “Releases”

I feel like as a small indie developer, doing my part for the community, if I develop a small feature that people would like, I don’t see the point of “holding it back” until I have enough new features to release a full version. So I take a more “gmailish” approach…where I just send out a new release everytime a cool new feature is added. In the end, all it takes to upgrade is copy/paste a few files….

@Jemgames : if you are talking about my library I have to agree i haven’t released very stable versions but that is why i keep the alpha label. If you think the releases are un-featured you haven’t looked what happened behind the screens. You also have to see the features in relation with the whole project. If the project is a library features are not going to be as impressive as in a (semi-)application.

@jTaby : if you are considering to drop versions how are you going to separate parallel not compatible versions? Or don’t you maintain parallel versions?

xwero, yeah, I’m too small and busy to maintain two incompatible versions. There’s just “the” version.