GitHub labels related to dependency validation

[denelon]

We're working on the dependency validation logic for the community repository. I'd like to get feedback on label titles.

A manifest would create a circular dependency.

• "Validation-Recursive-Dependency"

Removal of a manifest would break other packages with a dependency if it is removed.

• "Validation-Dependency-Removal"

A manifest has a dependency that isn't in the repository.

• "Validation-Dependency-Missing"

There are some subtle nuances with removing a package all together as opposed to deleting the "last" manifest version that meets a dependency requirement.

There is also a difference between depending on a package that doesn't exist as opposed to depending on a version of a package that does not exist.

For the nuanced cases, we could provide different labels or simply provide more detail in the PR comment. What would you prefer?

Mentioning Community Moderators:

@ImJoakim, @ItzLevvie, @jedieaston, @KaranKad, @OfficialEsco, @quhxl, @Trenly

[Trenly]

"Validation-Dependency-Missing"

I personally would prefer "Validation-Missing-Dependency"

I think there also needs to be Validation-Unsupported-Dependency for the WindowsFeatures and the WindowsLibraries

Maybe Validation-External-Dependency for any marked external dependencies, even though they are currently unsupported. It would give moderators and repo admins a chance to at least look at the external dependencies and vaidate them separately.

For the nuanced cases, we could provide different labels or simply provide more detail in the PR comment. What would you prefer?

For the nuanced cases in the original post (last version vs package removal / missing specific version) I would say posting in the comment is sufficient.

I think there also needs to be Validation-Dependency-Conflict. Maybe not now, but eventually, especially if/when MaximumVersion is added for when following the full path of a dependency causes there to be a conflict. But, this may also need consideration of whether or not package versions can be installed side-by-side