Posted by: Anonymous
[ip: 71.35.129.95]
on June 07, 2008 08:35 PM
Arrrrrgh.
Release quality bars, feature implementation order, and which versions are deemed "feature complete" enough to warrant ongoing support, are all part of release planning. This has nothing to do with version numbers, and everything to do with project management (which most FLOSS projects don't have solid, dedicated resources for).
Communicating with potential users to indicate the project's maturity and feature-completeness; which versions are more stable vs. more featureful; the level of support that the project offers, and for which versions; and so forth, are all part of public relations. Again, this has nothing to do with (useful, development-driven) version numbers, and everything to do with marketing (which most FLOSS projects again don't have solid, dedicated resources for). Real Developers despise the ever-present "marketing" version number, because it defiles all the meaning carefully wrapped into a real version number to instead create a number that's easier to sell.
In FLOSS, there is a generally accepted (and practiced) numbering convention for the meaning of that major.minor.micro triple. Major bumps happen only when backwards-compatibility is broken (or made non-native, deprecated, or otherwise inconvenienced or jeapordized by future development). Projects with large major numbers are either a Bad Thing (they can't design and keep breaking their APIs to fix problems; the project keeps changing hands and being rewritten; they just don't care about backwards compatibility...), or are using a "marketing" version number. Minor version numbers indicate backwards-compatible changes -- almost always new features. Large minor versions tend to be a good sign -- the dev team is active, they release often, they're good about adding features, and they aren't breaking compatibility. Micro version numbers indicate bugfix level; large values here indicate that the team either focuses bug-fixing on designated releases (a good thing), or makes releases with lots of bugs (not so good).
People not following the above are out of line with the majority of the FLOSS world. But that's exactly why distros add an extra layer of translation, providing "stable" and "unstable" tags (not that they always get it right). It's a nice, pretty, marketing front-end -- which is far easier to digest than the life's story of every project out there. However, that's a completely different target audience than dev-to-dev, which is what the version number is intended for. Version numbers aren't out of control, so much as you're trying to use them for something they're really, really not meant to do: market.
Learn about Linux
Download Linux
Get Linux help
Version labeling: Know the Target Audience
Posted by: Anonymous [ip: 71.35.129.95] on June 07, 2008 08:35 PMArrrrrgh.
Release quality bars, feature implementation order, and which versions are deemed "feature complete" enough to warrant ongoing support, are all part of release planning. This has nothing to do with version numbers, and everything to do with project management (which most FLOSS projects don't have solid, dedicated resources for).
Communicating with potential users to indicate the project's maturity and feature-completeness; which versions are more stable vs. more featureful; the level of support that the project offers, and for which versions; and so forth, are all part of public relations. Again, this has nothing to do with (useful, development-driven) version numbers, and everything to do with marketing (which most FLOSS projects again don't have solid, dedicated resources for). Real Developers despise the ever-present "marketing" version number, because it defiles all the meaning carefully wrapped into a real version number to instead create a number that's easier to sell.
In FLOSS, there is a generally accepted (and practiced) numbering convention for the meaning of that major.minor.micro triple. Major bumps happen only when backwards-compatibility is broken (or made non-native, deprecated, or otherwise inconvenienced or jeapordized by future development). Projects with large major numbers are either a Bad Thing (they can't design and keep breaking their APIs to fix problems; the project keeps changing hands and being rewritten; they just don't care about backwards compatibility...), or are using a "marketing" version number. Minor version numbers indicate backwards-compatible changes -- almost always new features. Large minor versions tend to be a good sign -- the dev team is active, they release often, they're good about adding features, and they aren't breaking compatibility. Micro version numbers indicate bugfix level; large values here indicate that the team either focuses bug-fixing on designated releases (a good thing), or makes releases with lots of bugs (not so good).
People not following the above are out of line with the majority of the FLOSS world. But that's exactly why distros add an extra layer of translation, providing "stable" and "unstable" tags (not that they always get it right). It's a nice, pretty, marketing front-end -- which is far easier to digest than the life's story of every project out there. However, that's a completely different target audience than dev-to-dev, which is what the version number is intended for. Version numbers aren't out of control, so much as you're trying to use them for something they're really, really not meant to do: market.
#