Hmm. Even with tag
--pr-wo-labels it still excluddes them

Example:

github_changelog_generator -u vas3k -p vas3k.club --no-issues-wo-labels --pr-wo-labels

Using these options:
:date_format=>"%Y-%m-%d"
:output=>"CHANGELOG.md"
:base=>"HISTORY.md"
:issues=>true
:add_issues_wo_labels=>false
:add_pr_wo_labels=>true

To me, it sounds like an option for a very strict project. "All labeled or not visible" to have no false positives.

For that strict workflow, perhaps some diagnostic check "are there unlabeled issues/PRs in this range?" would be useful? Idk, I didn't use it like that.

To support an "editorial hand" in the making, I've only used skipping, to exclude issues/PRs by label.

The strict workflow could be seen as the polar opposite of my usage.

I think your suggestion makes sense. Introducing it opens questions I can't answer "Are people relying on the old behavior? Would their regenerated CHANGELOG documents look wrong due to inclusion of old unlabeled PRs?" The fix for them would be to label those PRs skipped. There's a workaround.

So, I'm for the change.

Thanks. There are several points:

1. "are there unlabeled issues/PRs in this range?"
   (from internal GitHub structure PR is a subset of issue)
   Imo: from the user perspective: Issues and PR's - is 2 different entities.

as the fact: we have an option "--pr-wo-labels"

2. Would their regenerated CHANGELOG documents look wrong due to the inclusion of old unlabeled PRs?

1. we have to bump minor version with this change (so, it means, that changes could be done)
2. we have to support backward compatibility (it means, the way, how they can achieve the same result as before.

So my option is to do 3 types of options:

--skip-empty-labels
--no-issues-wo-labels
--no-pr-wo-labels

So with the usage of 1 - everything would be the same as before.

And then the rest to will work correctly

I have just tried with the example above (github_changelog_generator -u vas3k -p vas3k.club --no-issues-wo-labels ) and it correctly includes pull requests without labels, and excludes issues without labels.

So, I think this issue can be closed.