On Fri, Aug 20, 2010 at 10:43 PM, Joshua D. Drake <j...@commandprompt.com> wrote: >> True, we don't always have the best track record for bumping major >> releases. (ponders) Hmmm...I'm rethinking my immediate rejection of the >> idea now. 7.3 to 7.4 should have been 7.3 to 8.0. Certainly it was more >> major than 8.0 to 8.1 was, for example. Consider me a very weak -1 >> and open to persuasion. :) > > Are we losing something by going to a notably simpler scheme of > versioning? Is there a problem we are creating? Are we arguing for the > sake of arguing?
It's possible that we're arguing for the sake of arguing, but it's so much easier to have an opinion on version numbering than to have an opinion on how to fix dependency problems in parallel restore. So maybe we're all just letting off some steam. With respect to simplifying the version numbering schema, I kind of like the one we have, nonwithstanding the problems it creates (namely, that people think 8.3.0 to 8.4.0 is a smaller change than it really is; for some reason, they also tend to think 8.4.0 to 8.4.1 is a bigger change than it really is; and of course they also think that 8.1.0 to 8.2.0 is the same size change as 8.2.0 to 8.3.0, which isn't true either). 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? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers