Re: [HACKERS] standardized backwards incompatibility tag for commits

2017-03-27 Thread Bruce Momjian
On Sat, Mar 25, 2017 at 04:15:39PM -0400, Tom Lane wrote: > Andres Freund writes: > > Seems like it'd be good to standardize how we're declaring that a commit > > contains backwards incompatible changes. I've seen > > - 'BACKWARDS INCOMPATIBLE CHANGE' > > - 'BACKWARD INCOMPATIBILITY' > > - a lot

Re: [HACKERS] standardized backwards incompatibility tag for commits

2017-03-27 Thread Robert Haas
On Sat, Mar 25, 2017 at 4:15 PM, Tom Lane wrote: > Andres Freund writes: >> Seems like it'd be good to standardize how we're declaring that a commit >> contains backwards incompatible changes. I've seen >> - 'BACKWARDS INCOMPATIBLE CHANGE' >> - 'BACKWARD INCOMPATIBILITY' >> - a lot of free-flow

Re: [HACKERS] standardized backwards incompatibility tag for commits

2017-03-25 Thread Tom Lane
Andres Freund writes: > Seems like it'd be good to standardize how we're declaring that a commit > contains backwards incompatible changes. I've seen > - 'BACKWARDS INCOMPATIBLE CHANGE' > - 'BACKWARD INCOMPATIBILITY' > - a lot of free-flow text annotations like "as a > backward-incompatibility"

[HACKERS] standardized backwards incompatibility tag for commits

2017-03-25 Thread Andres Freund
Hi, Seems like it'd be good to standardize how we're declaring that a commit contains backwards incompatible changes. I've seen - 'BACKWARDS INCOMPATIBLE CHANGE' - 'BACKWARD INCOMPATIBILITY' - a lot of free-flow text annotations like "as a backward-incompatibility", "This makes a backwards-inco