On 05/13/2016 07:18 PM, Mark Dilger wrote: > My main concern is that a commitment to never, ever break backwards > compatibility is a commitment to obsolescence. It therefore makes sense to > reserve room in the numbering scheme to be clear and honest about when > backwards compatibility has been broken. The major number is the normal > place to do that.
The problem with that idea is that *minor* backwards compatibility breakage is much more likely in each-and-every version than major breakage is at any time in the foreseeable future. The last major breakage we really had was version 8.3, which if we'd been going by compatibility should have been 9.0 (also for other reasons). And if we adopt the "backwards compatibility" approach, then we'll just be switching from the argument we're having now to the argument of "is this enough breakage to rate a .0? Yes/No?". Which argument will be just as long as this one. So, my vote is now +1 to go to the 2-part numbering scheme. -- -- Josh Berkus Red Hat OSAS (any opinions are my own) -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers