@scanon the expectation here is that the reasoning you’ve provided (along with any other salient reasons) would be part of what goes in a README explaining why there hasn’t been a tagged release in years, as part of a proactive, functional effort.
I appreciate you asking if there’s anything that I need and expressing that you’d be happy to create a tag in the meantime, but I think that’s an entirely separate discussion.
Let's maybe pivot to that discussion here.
_TestSupport so probably not super duper problematic-lm link command) and similar building- and linking-related fixes might be helpful to some folks?Complex: Sendable) would be really good to have to keep up with the timesReal.pow and Complex.pow edge cases) would be nice to have; the Complex ones are more niche of course and I know you've refactored the files, so probably non-trivial to cherrypickVatsal has contributed a lot of input over the years, some of which i agree with, and some of which i do not, but i never felt that the way he delivered it was “hostile” towards any individual, or even the Swift Community as a whole.
Confidence and Trust are entirely in the eyes of the beholder. it is an inherent part of the job of Any of Us who develops Technology, to convince others to have Confidence and Trust in that Technology. it’s not hostile to say that, given some Observations, you haven’t reached the point where you can place your Confidence or Trust in something.
i don’t think we want to discourage people from pointing out that some code bases are not maintained well. there will always be more Code in existence than there are Humans around to maintain it, unless the Humans only very recently began writing Code.
imagine, if we never said any code bases were not maintained well. What If Everyone Did This? does anyone really believe that a community that rates all of its own code bases 5/5 Stars for fear of coming across as ”hostile” would succeed in the long term?
it’s not hostile to say a code base is not maintained well. i have lots of Swift Packages that, for long periods of time, were not maintained well, and often attracted profuse Complaints that they were not maintained well. my swift-noise library was in such a state for years, until some Amazing Volunteers showed up and helped me get the Project back into Serviceable Condition. if people Complain about your Code, all that really means is that you are a prolific author of Code.
i think Vatsal was careful to criticize only the Projects and not the Individuals who contributed to the Projects. i’m not seeing him making any attacks on anyone in particular, or the Swift Community as a whole.
Because they're part of a cohesive larger feature set, and I do not want to push it out into the world before I am satisfied with the overall design. For instance, two of the PRs you reference are likely to see API changes in the future (removing the stochastic rounding "mode" because of API and optimizer limitations).
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.
@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).
That's fine! The benefit of an open source package is that you can iterate and version as much as you want. There's no need to wait four years to ship something because you want to wait for a particular optimization to be possible. You can ship now and either add to the API later or make a major version release which completely revamps the API. Obviously, doing that too often is disruptive but that would be on the scale of multiple breaking releases in a year, but one in (over) four years would be fine.
One of the big impacts that Apple's "official" open source libraries have is to suck the air out of the room for any other similar tool or library. We saw it with SPM vs. CocoaPods (and Carthage) and we see it with these libraries (even though their lack of support for CocoaPods greatly limited their adoption in the early years). The mere existence of these libraries makes it difficult for other, similar solutions to catch on, which is exacerbated by SPM's inability to easily swap out project dependencies with forks. All this added together means we have core components of the Swift ecosystem locked in place (to me, this is especially true of swift-async-algorithms) while the community clamors for more (though not necessarily here). Add to that the Swift community's aversion to dependencies in the first place, which often means teams are limited to such "official" libraries (and those business people buy without talking to those teams), and we have core parts of the open ecosystem just not keeping up. (At least on Apple platforms, other platforms have to use open source libraries to do anything, so the issue isn't as severe.) Were these packages created by anyone other than Apple (or if SPM made it easy), they would've been forked long ago.
So while I'm happy these libraries exist (the more Swift experts making contributions the better), it would be much better for the community if they were managed more like typical open source libraries and less like the Swift standard library.
It's our goal to never make breaking changes to these projects. In this regard, they are somewhat atypical for open-source packages (at least modern move-fast semver server packages; in the older open-source world this approach was more common). We will not always achieve that, but in general we want them to meet the same source-stability standards as we have for the stdlib.
@scanon I would like to understand your thoughts on whether this may (despite best efforts) significantly hinder adoption to the point of being counterproductive.
Adding swift-numerics as a dependency pinned to a non-tagged commit has been considered risky in some of the teams that I've worked with. It could certainly be the case that folks in these teams (myself included) are not appreciating the stated goals and what means in terms of practice.
My personal estimator (but one that I've known my peers to share) for the 'health of a package' includes factoring in whether warnings introduced by recent (stable and non-beta) versions of the Swift toolchain are being addressed. That does not seem to be the case for the commit for the last tagged release (image attached, I just downloaded the last release and opened it with Xcode 16.2). No stated goals could change the fact that this is the case well into the public release of Swift 6.
I understand that a fix for this has already been made in main, but if the timeline for releasing said fix is hindered significantly for whatever reason, it does downgrade the package's health for me in consideration as an external dependency.
For my own versioned OSS Swift packages, I personally do feel that it is a sign of poor maintenance, and have been criticized for it by external contributors.
On a slightly tangential note, but relevant to the warnings in the screenshot: I personally have gripes with the Swift 6 language mode introducing this as a warning. IIRC there's been some discussion on allowing folks to turn this warning off, I'm not sure whether those discussions have materialized.
That's rather unfortunate. There is still a huge amount of room for iteration using deprecation and such (many other libraries have been very successful in that way) as well as additive changes. As long as the public API wouldn't break, that a certain optimization is missing isn't necessarily a blocker. I would encourage more clearly documenting these limitations, the expected release cadence, and the types of PRs the project might accept. Being clear on the state of existing PRs would also be the polite thing to do for the author.
(But I've mostly been thinking of swift-async-algorithms in this discussion, which is a key component when adopting Swift concurrency as a replacement for older systems like Combine.)
(Also, @vatsal's analysis is spot on. Given the skepticism with which dependencies are generally viewed in the Swift community, one that hasn't seen a release in four years is almost guaranteed to be dismissed out of hand. I've had to have conversations about keychain wrappers (an API which hasn't changed substantially in 20 years) that hadn't had a release in six months.)
Why on earth? Doesn't that defeat the purpose of treating them like Boost libraries?!
I was under the impression that having them split out of the standard library was so that they could be iterated on more quickly than the standard library, and without adhering to the same strict standards as the standard library!
