version numbering

[Matthias Andree]

David Relson <relson at osagesoftware.com> writes:

> I don't agree.

And I don't believe we're that far apart as it seems at first glance.

> We're presently at 0.10.2 and there are two outstanding patches for
> fairly minor problems.  Until we have a new major feature, there will
> be 0.10.2.x bugfix release(s).  As new (minor) features are added, the
> version should bump up to 0.10.3, then 0.10.4, etc.  New major
> features will take us to 0.11.0, 0.12.0, etc.  This is how I think
> versions should be numbered.

I'm not adding features to the 0.10.2 branch. This branch is bugfix-only
for me. Features regardless of size of importance go onto the main trunk
IMHO, and I don't think we'd do full releases for minor features just
yet, and even if we do, there's nothing that prevents us from using
0.11.0 for minor features that we want in a release.

(I'll consider tuning for speed if it's non-invasive as a scalability
bug fix though, so I'm not taking the term "bug" too strictly.)

> "Stable" is a separate matter.  At any given time bogofilter has a
> stable version.  Likely there is also a bugfix release and possibly an
> unstable (beta) version.  It seems like there may be different criteria
> for promoting a release to "stable" and they depend on the software
> version.

Bugfixes for stable versions are usually five lines or something, they
are put to bogofilter-dev scrutiny or something, and then applied
without further beta phase. IMO we don't need fourth-level version
numbers for official releases. I tagged 0.10.2.1 because I needed a
distinction from 0.10.2 and 0.10.2.cvs was already given to the main
trunk.

The version number and stableness are actually orthogonal, because as
you suggest, the arrangement into sourceforge packages determines the
state.

> To summarize:  The next bugfix release will be 0.10.2.1.  The next minor
> release will be 0.10.3.  The next major release will be 0.11.0

I'm not fond of that, we'll effectively have three branches then. Bugfix
release branch, minor feature branch, major feature branch. IMO we have
the comfortable position of declaring beta and 0.x.y -- so we don't need
to distinguish minor versus major, just "fix-the-latest-release" (which
could have been 0.9.2 and 0.9.3 if we merged the patches I uploaded to
sourceforge, or 0.9.1.3, 0.9.1.4 by your nomenclature).

So my summarized suggestion is: next bugfix on the current stable
0.10.3, next release 0.11.0 after features have been added. I'll concede
0.11.0.x for beta versions, but I'm not keen on 0.10.n.m for stable
releases.

IMO we shouldn't have releases too often either, they bind a lot of
ressources for full-scale bugfixing, restoring portability and they
defer real work. One, maybe two a month are enough. I doubt we manage
more than one.

-- 
Matthias Andree