Re: Version Numbering

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

> It's possible that we're arguing for the sake of arguing

No it's not! ;)

> It's nice to be able to keep track of the major version
> number without running out of fingers (at least for a few more years)
> and it's nice to be able to bump the major version number when we do
> something to totally destabilize the tree^W^W^W^W^Wreally cool. Or at
> least, I think it's nice. Again, YMMV, IMHO, etc.
>
> If the Windows port was the primary justification for the 8.0
> designation, and HS/SR are the justification for the 9.0 designation,
> what will 10.0 be?

Therein lies the problem: our decision to do a "major" bump is inconsistent
at best, and wildy confusing at worst. Does a new feature really constitute
a major bump? Perhaps so, as with 9.0 SR/HS, but in that case there have been
other times we should have bumped the major for some new feature and did not.
What about major internal changes and libpq version bumps? You might think
those would always be a major change, but they are not. We went from 7.2
to 7.3 without considering how major it is (hello, schemas!). What about
end-user compatiblity? I sometimes suspect few hackers on this list realize how
completely disruptive, annoying, and painful the removal of implicit
casts was in 8.3. That would have been a major bump in my book at least.

I think in the future we should consider lowering the bar for a "major"
release, as it's better to err on that side.

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
PGP Key: 0x14964AC8 201008202330
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkxvSS0ACgkQvJuQZxSWSsjQ0QCfW/2l065L0XEO6kmnARpjgqJ5
t2EAn3xM8w5f5xmHl3EZAmXhxXFpEREo
=/CYr
-----END PGP SIGNATURE-----