I think the project should spend a moment thinking through version
naming, rather than just whole numbered "releases". The best practice in
version numbers is for the versions to indicate compatibility as well as
completeness. This practice uses numbers to show differences in
features, file formats and APIs, by incrementing three numbers, and a
build/testing release number:
The features ("major") version number is incremented when the user
features, especially the UI, change substantially, typically when common
user features or UI change, not just new ones added, unless really
substantial new ones are added. It helps people to see whether their old
skills will use the new version without changing their skills (or
requiring training, or documentation).
The file formats ("minor") version number is incremented when the file
format changes incompatibly with the old version. It helps the user
decide whether to upgrade their stored data, or whether to stick with
the old version if there's no data migration tool. It says whether two
instances will work on the same stored data or not.
The API ("subminor") version number is incremented when the
programmatic API changes, so automated invocation of the new version
might not be compatible. This number is for libraries, apps with network
APIs, and apps with other APIs that other programs must connect to, or
fail in incompatibility.
The release is one of "alpha", "beta" and "release", though "rc" for
"release candidate" can be one of the last betas, which just gets
renumbered when released. "Release" is usually just omitted, in favor of
just a final number. "Alpha" is a version being tested by the developers
(setting specs, designing or actually coding); "Beta" is being tested by
anyone not also developing it. Once released, changes that don't change
the features, the file format or the APIs merely increment the release
number (starting with either 0 or omitted.
That "data format" of the version number does more than just show that
a version supersedes a lower numbered version. It shows exactly what
has changed in the structure of components that most directly affect the
decision to upgrade. The question of whether to increment numbers is an
objective one, not subjective. If you haven't considered the value of a
more informational release number, now is the time. Once you've released
"1.0", you have until you've released the next version to get your
version numbering discipline together without also telling the world
that you don't have any :). If you use "compatibility numbering", you'll
just call it "1.0.0", and start counting each aspect from there.
Best of luck with the first complete release, however you number it. A
Sip-Communicator by any other name would still sound as sweet :).
On Thu, 2008-11-27 at 13:26 +0100, Emil Ivov wrote:
A quick note to let you know that this Sunday we'll be drawing the
line for new features that get into the 1.0 branch. All contributions
that we receive after that will be added to the 2.0 branch.
In other words if you have a super-duper patch that you would like to
absolutely see in the 1.0-rc1 release (and the subsequent 1.0) then
now's the time to submit.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
(C) Matthew Rubenstein