You miscredit me with knowledge and an understanding that I did not have at the time of writing what you’re quoting, nor was it the basis for the view that I expressed (happy to elaborate upon this if the rest of the post doesn’t make it clear).
I looked at swift-numerics as a package, saw that the last tagged release was made years ago despite there being numerous commits since then, and saw no obvious reason in the README (or discussion in the GitHub issues) as to why that is the case.
The idea that you’re calling misplaced is not one that I held, or hold. You may still feel that what I expressed is inappropriate, and I’m open to being educated as to why in that case.
It stood out as atypical to me in the sense that the other packages I’ve seen fall in this category of “many years between last tagged release and latest commit” are (to the best of my knowledge and experience) typically considered unhealthy in a client’s consideration of the health of a prospective package dependency. This is also a point of consideration that has been brought up by my peers when I’ve proposed integrating swift-numerics in certain projects that I’ve worked on. This stood out as relevant to me in the consideration of absorbing these packages into the Swift standard library.
I wasn't commenting on the pace of new feature release, nor was I expressing any complaint there. As for the very last bit, I do not perceive a link between quality and release cadence, I do perceive a link between API surface stability and release cadence. For example, I do not know how swift-numerics will change if it adopts the Swift 6 language mode, and it does not inspire confidence nor trust in my view of the health of it as a package dependency within my projects.
None of this is intended as an indictment or even a comment on the quality of code solely on the basis of its release cadence, I apologize for having it come across as that if that’s the case here.
Reading your and @scanon's replies has actually given me some new insight that I did not possess nor do I think I would've been able to obtain on my own (on the matter of cadence of release). It's raised new questions for me that are wholly separate to the discussion here - around the different types of release strategies that I'm now perceiving across this category of supplemental packages, and the tradeoffs thereof.
Edit further clarifying "not maintained well" and "massive drift"
@ben-cohen some of my subsequent comments highlight the specific issues that I see in the last tagged release.
In your take, you reference feature work in multiple places and (I believe) incorrectly presume that my basis for the view of "not maintained well" has anything to do with the cadence or the current state of feature (new or old) work.
Addressing the compiler warnings for retroactive conformances is (in my opinion) neither a bug fix (i.e. in that it can be ignored without any change to correctness of the program) nor feature work.
It is part of what I consider maintenance, it does factor into my consideration of whether something is maintained well or not. Proactiveness (within a reasonable period of time) in addressing easily fixable warnings with newer Swift toolchains that have been released to the public is orthogonal to feature work.
This kind of maintenance is not new nor uncommon. I frequently have to update my own OSS packages to address new diagnostics/warnings that have nothing to do with feature work.
If there is a massive gap of years between the last tagged release and the latest commit, one learns to expect that importing this package is likely to introduce warnings accrued by way of changes to the language toolchain over the years, even if the quality or functionality of the package is expected to remain the same.
I do not consider it to be rock throwing to point out a perceived link between release cadence and this kind of maintenance debt (maintenance debt that is separate from the quality of the code but pertinent to the health and maintenance of a package from a client's perspective).