What's your prefered method to name your software releases?

Question

What's your prefered method to name your software releases? Like Microsoft: alpha - beta - final - service pack... Like Google: gmail beta - beta - beta - beta - :) Like some softwares: 0.2 - 0.3 - 0.9999...

Answer 1

I prefer the prototype, alpha, beta, GA method. This allows me to communicate the current status of the software to the users/clients. Along with that I provide version numbers .2, .3, .4.

• The first digit representing major milestones.
• The second digit represents incrementing the release (I generally release once a week so I increment the second digit).
• The third digit is used for patches, so if there is a bug in the code that is fixed outside of the normal release schedule I use the third digit.

Answer 2

We don't release alpha/beta software to our customers. Therefore we simply use:

• x.0 (for major releases, containing important/lots of new features)
• x.1, x.2, etc. (for minor releases containing minor new features and enhancements)
• x.y.1, x.y.2, etc. (for bugfixes/maintenance releases)

(where x,y = 1,2,...)

Answer 3

Major.Minor.Release.Build

While Release and Build increments should not contain "breaking changes" (for example have a different file format to store documents), i'm not absolutely sure if Minor releases are allowed to.

The meaning of the alpha, beta suffixes are for me:

Alpha/Preview: Hey, i got something that i want to show.

Beta: The feature set is complete so far, but there are some bugs left.

Release Candidate: I think that there aren't any (major) bugs left.

Final: There could be still bugs, but i have to release at some point ;-).

Answer 4

For small software just Major.Minor. If Major changes - some input files is not compatible with previous version. We are not prereleasing software to customers so same version is for testing and for final release.

Answer 5

Microsoft uses version numbering as well as the alpha, beta, GA monikers.

I think version naming depends a lot on what you're trying to accomplish. If you're releasing something for consumption and aren't trying to collect data from a beta period, don't call it beta. If you're not trying to preview the technology, don't call it alpha.

I work mostly with web apps at present, and we just number our versions as incrementing integers by when we deploy (1, 2, 3, 4, 5, etc.). There's no reason to have to get into complicated naming logic if no one cares about the versions anyway.

Answer 6

The way we have been naming our releases is typically Phase number. With most of our contracts being government projects we will roll out the first release and then will perform Phase 2, Phase 3, Phase 4 as the entity decides to move along with new feature requests (and acquires funding for said future developments).

Answer 7

Some open source software project name releases after the date they were released. For example Ubuntu 8.04 was released in April 2008 and Ubuntu 6.06 was released in June 2006. But Ubuntu is not the only Linux distribution that uses this method.

Of course each Ubuntu release also has a code name that is each time a different animal, combined with an alliterating adjective (the adjective also serves as a cutesy shorthand for insiders). Each release goes up in the alphabet so people can remember easily where to place a release in the steady stream. For example:

For example 6.06, dapper drake 6.10, edgy eft 7.04, feisty fawn 7.10, gutsy gibbon

Answer 8

I prefer the Linux kernel notation: major.minor.release.build, but i rarely use the .build part, and i don't use even/odd numbers for stable/development minors.