[collectd] Proposal for collectd version numbering scheme

[Florian Forster]

Hi Muralito,

On Sat, Apr 22, 2006 at 06:30:35PM -0300, Muralito wrote:
> During the past months i have seen what seems to ba a fast growing in
> the collectd version number.

yep, I (try to) stick to the paradigm ``release early, release often''..

> IMHO, if the development process is not affected, maybe it's better to
> have a clear version numbering scheme (i googled for it and haven't
> found anything related to collectd).

The scheme I use is very similar to that described by `APR' (Apache
Portable Runtime Project), found at the URL below. Basically that is:
- The major (first) number changes => This version is not backwards
  compatible to previous versions. Problems may be: RRD files changes
  (added/renamed DS, other config file syntax, ...). I.e.: If the end-
  user has to do anything else but restarting the daemon, the major
  version number changes/increases.
- The minor (second) number changes => New features have been included.
  This includes new plugins, new configuration options, etc. These
  releases potentially introduce new bugs. If you want to be sure to
  have a `stable' version you should possibly stay one version being.
  Bugs get fixed for the two most recent (minor) versions. Right now
  that's 3.8.x and 3.9.x.
- The patchlevel (third number) is increased for every bugfix. No new
  features or new code is introduced here (besides the code neccessary
  to fix the code, of course), so upgrading should not be a problem at
  all. For binary packages, sometimes nothing changes at all since all
  bugfixes where made in the build system..

For example:
- Version 3.9.0 changes the RRAs of newly generated RRD files. Old RRD
  files still work just fine, so only the minor version increased.
- Version 3.9.1 fixed some things in the build system and a bug in
  `liboping' code, therefore only the patchlevel increased.

Of course, I don't follow this rules like a religion: When in doubt, I
trust in common-sense. You'll most likely read a comment on it on the
mailinglist though.. When introducing a configfile, for example, I only
changed the minor version.

> Maybe having a stable release, and a testing or unstable release (I
> supose that most of us could only install the stable release on some
> servers, and the test version on a few test server(s).) Maybe this is
> not good because less people will be testing?

That's what I do/did with other projects. It's kind of a farce though: I
do new stuff and release it as `unstable'. I write to the mailing list
and ask for people to test it. If I'm lucky I get some feedback and fix
some bugs. But when is the thing stable? If a week without bugreports
passes? Or a month? Then again I find very obvious bugs in the stable
version in parts I don't personally use - and noone complained.

If people wish that I declare a version `unstable' first and `stable'
after x days without bugreports I'll do that, but personally I don't
think it's reasonable..

> I haven't seen the code, but other way could be to release two
> packages, one for the core an another one with the plugins. The idea
> behind this is that the core will be stable and have fewer releases
> than the plugins. Just like nagios and nagios-plugins.

That's not a bad idea.. I'll think about it..

APR's version numbering scheme:
<http://apr.apache.org/versioning.html>

Regards,
-octo
-- 
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20060423/396dfce3/attachment.pgp