Rename deprecate references

[rafaelfranca]

Problem

In my view, they are not really deprecated, since we recommend people to record them. And sometimes we say it is ok to keep them there for a while. I propose we rename this concept to explain better what it should be used for.

Proposals

packwerk_todo

This make explicit that fixing them should be done, and this is a list that teams should be working on to decrease.

Some people argue that not all references should be fixed though, so in this case the name doesn't fit.

Allowed references

If references are ok to exist forever in this file, we should call them allowed references.

Conclusion

Any other suggestions for new names? Is the current name ok?

[rafaelfranca]

cc @alexevanczuk @mclark

[exterm]

I don't think "forever" was ever the intention. I like packwerk_todo.

[mclark]

I think this is a great idea, +1 to packwerk_todo. As an alternative, package_todo could also work as it would be analogous to package.json.

[ngan]

How about package_todo.yml?

[ngan]

I just saw @mclark's message. Whoops! Yes, i agree, package_todo.yml sits nicely with package.yml

[alexevanczuk]

+1 to making this change. I'm in favor of package_todo.yml. packwerk_todo.yml feels like it should sit next to packwerk.yml

[alexevanczuk]

Question:

What do we think of having this be sequenced in three parts:

1. Have packwerk read package_todo.yml AND deprecated_references.yml and release this so users can migrate at their leisure
2. Release a pre-major version that adds a deprecation warning for use of deprecated_references.yml
3. Bump the major version

This way we can bucket this major version change alongside any other breaking changes we want to incorporate.

[alexevanczuk]

Addressed here: #242

Please share your feedback! I think we probably want to land this the same time we finish extracting privacy as a plugin so as to limit the number of major version releases, but also open to multiple major version releases if that's what the team prefers.