> I think the project has gotten to such a size, and such a number of
> developers, that this is feasible to do...we'd still have our major
> releases, but only have minor, not minor.minor releases...
Hmm. Pretty sure I don't agree that we have enough developers to
handle this...
> Instead of v6.5.1 after a month of v6.5 being released, we'd have released
> v6.6 as being the more current stable version...its just taking things one
> step further then what we've done recently with the release of v6.5.3...
OK, I *think* I understand your suggestion. If that is the way the
project goes, OK, but I'm not happy about it, really. If we had been
doing this scheme since v6.0, we would have gone from v6.0 to v11.3 in
2.5-3 years, with (from my saved tarballs and the release notes):
v6.0 (6.0 series)
v7.0 (6.1 series)
v7.1
v8.0 (6.2 series)
v8.1
v9.0 (6.3 series)
v9.1
v9.2
v10.0 (v6.4 series)
v10.1
v10.2
v11.0 (6.5 series)
v11.1
v11.2
v11.3
Oh, btw, virtually no minor release has new features (since they all
preserve DB contents and structure), just fixes for code breakage.
I'd like to put dates on the releases, to point out that in several
instances we went from vX.0 to vX.1 in two to four weeks :(
Actually, this is the slippery road to name and version escalation: we
should have released "PostgreSQL+", "PostgreSQL Pro", "PostgreSQL
Developers Edition", "PostgreSQL++", "PostgreSQL II", "PostgreSQL
Pro+", etc by now ;)
That way, we can have a v2.0 of a bunch of products, and people will
think we're doing real development without ever checking that we are.
Works for other folks, but I don't see what it buys us.
OK, I've had a bit of fun with this, and I'll shut up now (well,
maybe), but I don't think that escalating our version numbering fixes
problems, and just means that we have a "R10" (a la "Y2K") problem
sooner rather than later.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California