-----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 g...@turnstep.com PGP Key: 0x14964AC8 201008202330 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAkxvSS0ACgkQvJuQZxSWSsjQ0QCfW/2l065L0XEO6kmnARpjgqJ5 t2EAn3xM8w5f5xmHl3EZAmXhxXFpEREo =/CYr -----END PGP SIGNATURE----- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers