Gauging interest in doing a large-scale code change migrating everything from Lints -> CertificateLints

[aaomidi]

In #699 I introduced the ability to have more than just certificate lints. I now want to finish off this migration by moving all the existing lints to CertificateLints.

The next step will be fully removing the Lint interface, which is potentially a more contentious move since it might break lints folks have already made.

Do we have any concerns with doing the first part of this?

[zakird]

Makes sense to me.

[cardonator]

This makes logical sense as a shift. However, I do think there is a pretty big cost to some integrators depending on how it's done. For example, if you are an integrator and have added your own Lints on top of the lints provided by zlint, this could be a breaking change even just migrating existing lints to a new interface. It's less likely than step 2, but still a possibility depending on how the integrations are done.

[aaomidi]

Agreed on the last count. I've written a small tool to convert all the lints to CertificateLint in this project. I can imagine that being useful for folks who have built their own lints separately.

The decision to remove Lint/RegisterLint will be up to the maintainers here.

When I introduced the CertificateLint/RevocationListLint, generics wasn't officially "ready". Maybe before any long term decision is made, we can potentially look into generics for these lints again too?

[christopher-henderson]

Migration from lint.Lint to lint.CertificateLint via your tooling is fairly straight forward, and (as you've said) the real issue is how/when/if to remove the lint.Lint interface altogether.

...we can potentially look into generics for these lints again too?

Presuming that that this would be considered during the removal of lint.Lint then it makes sense as it is certainly a breaking change for library consumers. So bundling the consequences together would help reduce friction overall.