standardized backwards incompatibility tag for commits

Andres Freund <andres@anarazel.de> 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", "This makes a backwards-incompatible change"

Especially the latter are easy to miss when looking through the commit
log and I'd bet some get missed when generating the release notes.

Bruce might have a different opinion, but for my own part I do not think
it would make any difference in creating the release notes. The important
thing is that the information be there in the log entry, not exactly how
it's spelled.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Sat, Mar 25, 2017 at 4:15 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Andres Freund <andres@anarazel.de> 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", "This makes a backwards-incompatible change"

Especially the latter are easy to miss when looking through the commit
log and I'd bet some get missed when generating the release notes.

Bruce might have a different opinion, but for my own part I do not think
it would make any difference in creating the release notes. The important
thing is that the information be there in the log entry, not exactly how
it's spelled.

The other thing is that not all incompatibilities are equally
important. I think there's pretty much a continuous spectrum from
things that are laughably unlikely to cause problems for anyone in
practice ("hey, you fixed the server crash that I was relying on to
bounce my server!") to things that don't intentionally change
user-visible behavior but might easily still create problems for
people ("hey, your new expression evaluation engine is prohibitively
slow on my test case!") to things that create small but noticeable
user-visible changes ("hey, SELECT 1 the_new_keyword_you_just_added
now fails!") to things that break user SQL in a way that requires it
to be updated ("hey, you changed the definition of pg_stat_activity!"
or much more significantly "hey, i have to go add explicit casts to a
bunch of things that didn't use to need them") to things that cause
the same syntax to have frighteningly different behavior ("hey,
TRUNCATE now recurses to child tables!"). When people mention that
there is a backward-incompatibility in the commit message, they're
just saying that they think that behavior change from that commit is
particularly noteworthy. But I don't think there's any real
consistency among committers about which changes rise to the level of
requiring such an annotation. I doubt that "Backward-Incompatibility:
{Yes|No}" is granular enough to be useful even if we all agreed on
what it meant. "Backward-Incompatibility: TYPE_OF_INCOMPATIBILITY"
might be useful, but agreeing on a set of definitions and getting
everyone to remember to apply the tag in relevant cases might be hard.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Sat, Mar 25, 2017 at 04:15:39PM -0400, Tom Lane wrote:

Andres Freund <andres@anarazel.de> 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", "This makes a backwards-incompatible change"

Especially the latter are easy to miss when looking through the commit
log and I'd bet some get missed when generating the release notes.

Bruce might have a different opinion, but for my own part I do not think
it would make any difference in creating the release notes. The important
thing is that the information be there in the log entry, not exactly how
it's spelled.

Yes, it doesn't matter as long as it is stated somehow. I don't know of
any missing cases due to text differences.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers