Re: Version Numbering

From: David Fetter <david(at)fetter(dot)org>
To: Greg Sabino Mullane <greg(at)turnstep(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Version Numbering
Date: 2010-08-21 17:29:12
Message-ID: 20100821172912.GA7501@fetter.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Aug 21, 2010 at 03:34:35AM -0000, Greg Sabino Mullane wrote:
> > It's possible that we're arguing for the sake of arguing
>
> No it's not! ;)

Yes it is! ;)

> > 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.

"Disruptive to developers" is one sufficient criterion.

Another is "does some big thing simply that would have been hard or
impossible before."

Previous things like dblink, schemas and CTEs, and upcoming things
like synchronous replication, SQL/MED, parallel query, and (of course
;) writeable CTEs, would qualify under that second.

Open for discussion would be features like "Can spit out, on demand,
any subset of the dependency graph for an object."

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2010-08-21 17:30:15 Re: Version Numbering
Previous Message Joshua D. Drake 2010-08-21 17:25:31 Re: Version Numbering