Remove blacklist sensitive language

[lzchen]

We will be using "Exclude list" instead to refer to endpoints that are not going to be traced.

[nilebox]

If I understand correctly, this is a breaking change?
@aabmass please make sure that this is okay / we bump major release version and mention this in the changelog if we decide to merge this change.

[lzchen]

The packages that are breaking will be flask, django and pyramid. Giving the current versioning strategy (we update the packages that change with the core Opencensus package), which is currently at v0.7.10, what should we update this to?

[lzchen]

If we bump the major version to v1.7.0, it wouldn't really make sense in the future if other packages change and we match them to a new major version. Should we not have packages be updated in lockstep?

[aabmass]

For semver major versions < 1, minor version bumps are not compatible: https://semver.org/#spec-item-4. So from semver perspective, we don't need to do a major version bump.

If users are using the "compatible release" specifier (or stricter) like opencensus-foo ~= 0.7.0, it will not automatically start installing the next minor version.

[aabmass]

@nilebox I agree this isn't great for users, but I think from a versioning point of view it's ok. I remember there being some OpenCensus breaking changes guidelines where you should give 30 day deprecation notice -- do you remember if those were project-wide or just for one specific repo?

[nilebox]

I remember there being some OpenCensus breaking changes guidelines where you should give 30 day deprecation notice -- do you remember if those were project-wide or just for one specific repo?

I think it was documented in some repo, but couldn't find it.

[tpyo]

Think the breaking change could've been communicated in the changelog.

[lzchen]

@tpyo
Thanks for catching this. Updated the release notes.

[minotru]

Hello,
although semver has a special note about < 1 version, I have always (and many developers too, I guess) thought that x.y.z+1 version indicates bug fixes or internal changes without public API changes, while this parameter name change introduced breaking change. So using x.y+1 version might be a better idea, I guess.

I agree this isn't great for users, but I think from a versioning point of view it's ok.

But the software is built for users, not versioning, isn't it?