New version/tag build request

[tabarafael]

The most up to date tag is 12 months old already, but the repository is still getting recurrent updates.

[pohly]

The only non-code-maintenance PR is #361.

Is that really worth a new release?

[tabarafael]

I see that it doesn't seem to bring much value to this lib. You see, some FOSS checking tools like Mend will complain after 1 year without updates that the lib is abandoned.

So the options I have is to fork it and maintain it myself, or move to another lib (which is probably easier). Because to continue using this lib breaks the compliance contract of my company, and of the other many services that use a similar scan and rule

[thockin]

What a silly policy. It's not that this is abandoned, it's just "done". Does the policy have no provisions for "we talked to the code owners and there really are no changes to make"?

[tabarafael]

It is one of the most controversial policies, I can see that.

I think the idea is that even a feature complete tool may have issues, mostly security related, and they need to be fixed. So by requiring a minimum frequency of updates, it is a roundabout way of judging that the repo still has activity and in the case of some issue, it will be fixed.

[pohly]

It's a heuristic. Heuristics can fail, so the tool should have a way to override the heuristic.

[thockin]

I apologize. Policies are what they are, whether they make sense or not. Given that there is one change, I don't object to tagging it. @pohly ?

[thockin]

https://github.com/go-logr/logr/releases/tag/v1.4.3

[pohly]

I don't like that this sets a precedence of doing regular releases just for the sake of it, because those have a cost for everyone who is now forced to update go-logr by a different set of tools which keep dependencies up-to-date.

But I guess v1.4.3 can be justified also because there were some small changes.

[tabarafael]

Thank you guys!