<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 18.05.2018 10:55, Serhiy Storchaka wrote:<br>
<blockquote type="cite"
cite="mid:9a0fdca2-b9a7-aa7d-4007-e30e677940be@gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
17.05.18 21:39, Brett Cannon пише:<br>
<blockquote type="cite"
cite="mid:CAP1=2W7+YkTyUF9Ypye7w7iJq8n+iSgUi6VSn-jDy3xs_tg3uw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div>Maybe we should start thinking about flagging PRs or
issues as needing a What's New entry to help track when
they need one, or always expect it in a PR and ignore that
requirement when a 'skip whats new' label is applied. That
would at least make it easier to keep track of what needs
to be done.<br>
</div>
</div>
</div>
</blockquote>
<br>
The requirement of flagging PRs or issues as needing a What's New
entry doesn't differ in principle from the requirement of creating
a What's New entry for these changes. The latter is good, and I'm
trying always create a What's New entry for significant
enhancement or potentially breaking change. And even I sometimes
is unsure and don't document some important changes (like in
issue30399). Needed a look of yet one pair of eyes.<br>
<br>
As for requiring a What's New entry by default and introducing a
'skip whats new' label, I suppose this will add much <span
class="gt-baf-word-clickable">nuisance</span><span
id="result_box" class="short_text" style="" lang="en"><span
class=""></span></span>. Most PRs (except docs and tests
changes) need a news entry, but most PRs don't need a What's New
entry because their are bug fixes. Therefore a 'skip whats new'
label will be required much more times than 'skip news' or 'skip
issue' labels.<br>
<br>
</blockquote>
Since Python uses semantic versioning (<a class="moz-txt-link-freetext" href="https://semver.org">https://semver.org</a>), the
criterion for "what's new-worthy" changes is simple: they are
_public interface changes_ (which include visible changes to
documented behavior).<br>
(I maintain that changes to behavior that is not documented -- incl.
issue30399 -- are _not_ public interface changes, and whoever relies
on them does that on their own risk.)<br>
<br>
Reading previous What's New, I see that it is structured like this<br>
* Entries for major changes:<br>
* General design decisions<br>
* Changes that fall into a category (more recent What's New's
include about a dozen categories)<br>
* "Other": the list of the rest<br>
<br>
So, it makes sense to mark work items as "interface change" or
something, and optionally with a caterory if that category is
established.<br>
You can't make a mistake here 'cuz a public interface change
requires an edit to related documentation.<br>
<blockquote type="cite"
cite="mid:9a0fdca2-b9a7-aa7d-4007-e30e677940be@gmail.com"> A thing
that can help is a tool that makes a structural diff between NEWS
files for different versions and between different branches. It
will filter out bugfix changes. The simple 'diff' is not well
appropriate because entries can be in different order, and news
entries now are scattered between several files, and news entries
for previous version sometimes should be searched in different
files, and sometimes should be searched on a different branch. The
text of entries in different versions can also be different
because the same issue can change the behavior on the master and
backport the part of changes as a bugfix.<br>
</blockquote>
Not all bugs apply to all, or multiple branches, so that wouldn't
filter them out reliably.<br>
<blockquote type="cite"
cite="mid:9a0fdca2-b9a7-aa7d-4007-e30e677940be@gmail.com"> <br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Python-Dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Python-Dev@python.org">Python-Dev@python.org</a>
<a class="moz-txt-link-freetext" href="https://mail.python.org/mailman/listinfo/python-dev">https://mail.python.org/mailman/listinfo/python-dev</a>
Unsubscribe: <a class="moz-txt-link-freetext" href="https://mail.python.org/mailman/options/python-dev/vano%40mail.mipt.ru">https://mail.python.org/mailman/options/python-dev/vano%40mail.mipt.ru</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Regards,
Ivan</pre>
</body>
</html>