Robert Haas wrote: > On Fri, Dec 18, 2015 at 9:52 AM, Robert Treat <r...@xzilla.net> wrote:
> > Perhaps not with rock solid consistency, but we've certainly used the > > argument of the "not a major major version release" to shoot down > > introducing incompatible features / improvements (protocol changes > > come to mind), which further lends credence to Jim's point about > > people expecting backwards incompatible breakage to be in a major > > major version changes. > > My memory is that Tom usually argues pretty vigorously against the > idea that there's anything special about a first-digit bump in terms > of incompatibilities. But your memory may have a longer reach than > mine. We haven't made a lot of first-digit changes, and if I recall correctly it has been mostly a matter of PR, based on sets of particular features, rather than objective technical criteria (such as changes in backwards compatibility or such). For instance we changed from 7 to 8 mostly because of adding the Windows port and PITR, and from 8 to 9 because of replication -- you could think of those as major steering changes, with large influence in what came afterwards. I don't know what would be a good reason to change from 9 to 10, but certainly we shouldn't do it just to remove a couple of GUCs -- much less do it for no reason at all (which would be what "but 9.6 is too close to 9.10 already" would boil down to.) I sure hope we're gonna find some good reason to do it before 9.10 actually comes around. > > Given the overhead from a development standpoint is low, whats the > > better user experience: delay removal for as long as possible (~10 > > years) to narrow the likely of people being affected, or make such > > changes as visible as possible (~6+ years) so that people have clear > > expectations / lines of demarcation? > > IMHO, it's almost hopeless to expect users to prepare for incompatible > changes we want to make. When we try to force it, as we did with > standard_conforming_strings or the 8.3-vintage casting changes, we > cause a lot of user pain and that's about it. People don't say "ah, > these changes are coming, I need to adjust my app to be safe in this > new world"; instead, they say "crap, I can't upgrade, PostgreSQL > hackers suck". We spend our days and nights worrying about this > stuff, but real users don't. They just got knocked over when the > change hits. Agreed on this. (As anecdote, I remember people relying on add_missing_from, and never fixing the apps, until they absolutely had no choice because the GUC was removed, even though I warned years in advance.) On the other hand, while I agree with you that we should strive to maintain backwards compatible options for a long time, and that in this particular case I see no reason not to wait a few more releases since it doesn't hurt anything, I don't think we should make this an iron-clad rule: I imagine there might be cases where there will be good reasons to break it sooner than those 10 years if maintenance becomes a serious problem otherwise. We will need to discuss each case individually as it comes up. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
