Not only that, but iOS 18.7.8 actually seems to be available to devices capable of running iOS 26 without any workarounds, unlike 18.7.3 through .6. It makes me wonder if those intermediate releases really were supposed to be available but weren't due to some issue on the distribution side that no one bothered to fix.
The improvements are solid! I think 5x6 was the right call...it's a good balance of being able to reuse strategies from 5x5 but also having to develop some new strategies.
Just note that listing is for an item from a third-party seller. Walmart's website includes listings from their third-party marketplace unless you explicitly filter them out.
> I've seen codebases that enforce these commit prefixes such as "chore", "feat", "bugfix" etc. Is there any real value to that?
It's a choice some teams make, presumably because _they_ see value in it (or at least think they will). The team I'm on has particular practices which I'm sure would not work on other teams, and might cause you to look at them with the same incredulity, but they work for us.
For what it's worth, the prefixes you use as examples do arise from a convention with an actual spec:
> Or otherwise you can enable the app exposé feature to swipe down with three fingers and it will show you only windows of the same app.
If you have an Apple keyboard, CTRL-F3 (without the Fn modifier) will do the same. Not sure if there are third-party keyboards that support Mac media keys, but I'm guessing there are some at least...
Welp, now that there is confirmation that lawyers are involved, the chances there will be any of sort of open and transparent reconciliation process have plummeted.
Er...FYI, your [2] link is to a discussion about an article written by the person to whom you are responding.
Personally, I think the reason this post about gem.coop has been flagged is that we've reached the point at which new HN threads about things related to the recent RubyGems shake-up quickly devolve into people rehashing the DHH "aspect" of it all. So it has become less about flagging the actual target of the post and more about flagging the parts of the discussion that seem to go nowhere.
There have been several releases with incremental but still notable performance improvements. The overall cadence has been pretty steady, intentionally targeting roughly one minor release per year since 2019-ish, with handfuls of quality of life improvements in each. Arguably RubyGems and Bundler are infrastructure, so the major feature is stability. What sort of big feature are you imagining is missing from your dependency management system?
Not sure what post you have in mind, but Kenji Alt-Lopez's video[1] on the topic is excellent. If I remember right, it's based on work he did with a well-known food publication (or show or something)...
This thread has probably run its course, and newer postings[1] have more information, but I'll respond anyway if it's helpful...
> How can they remove maintainers from their own projects? If my project is yawaramin/foobar...
The official RubyGems projects in question were under a GitHub organizational account, not a single user's account. A subset of the maintainers had the "owner" flag on the org. One of those folks basically initiated the takeover. See [2] for a more detailed recounting.
There is some more context on a post[1] in /r/ruby, including the fact that the maintainers and others had been working on a proposal[2] for a formalized organizational governance structure as recently as yesterday. The latter also adds some context into Mike McQuaid's involvement: the proposal was influenced by the structure put in place by the Homebrew project.