This is where my outsider's perspective falls short: assuming that the old release maintainer isn't actively preventing the project from appointing a new release maintainer, what stops them from just keeping on?
Deviations from their previous release schedule are certainly noteworthy, but release schedules also naturally length as projects mature.
And then there's the Theseus-type questions: if Jekyll changes its name because the current maintainers have lost access to the RubyGems credentials, is it really not Jekyll anymore? It occurs to me that OSS is replete with `${project}-ng` namings, the `ng` suffix typically indicating that the project serves the same purpose as its original form but has been moved to a different namespace for whatever reason. If Jekyll's current maintainers were to publish `jekyll-ng` on RubyGems, I'd be inclined to call that a continuation of the original Jekyll for all extents and purposes.
I'm not familiar with Github release permissions because it's not a process I've ever used, but I assume it's a different capability from being able to push patches. A "release maintainer" & repo owner who won't release or isn't adding release capabilities isn't "actively preventing" anything; they are simply not doing anything.
At this rate, if the release maintainer continues to ghost the project (including by refusing to make any clear public announcement), Jekyll users are going to have to fork. You can't wait forever.
> but release schedules also naturally length as projects mature.
That's why I pointed out they had been maintaining a very steady monthly release schedule for years beforehand (and just look at the total release count!). Plus, "maybe they don't need to do a release" is rather contradictory with "this project is in rude health, look at how many patches they're receiving piled up in the (unreleased) HEAD!"...
> I'm not familiar with Github release permissions because it's not a process I've ever used, but I assume it's a different capability from being able to push patches. A "release maintainer" & repo owner who won't release or isn't adding release capabilities isn't "actively preventing" anything; they are simply not doing anything.
This is a point of confusion, since GitHub now has a few different things that could be called "releases": tags (a Git thing), tags that are labeled as "releases" (a GitHub thing), and released packages via one of GitHub's package indexes (including one that behaves like RubyGems).
Anybody who has push access to a repository should also have access to the first two, and probably has access to the third. The first is a Git-level consequence of access, and the second is just sugar on top of tags ("releases" don't behave any meaningfully different, and many projects do releases without using the release labeling). IOW, they should have sufficient permissions, as-is, to continue cutting releases. They might not have sufficient permissions to publish those releases to RubyGems, but that just means renaming the package to `jekyll-ng` or using GitHub's index instead.
> Plus, "maybe they don't need to do a release" is rather contradictory with "this project is in rude health, look at how many patches they're receiving piled up in the (unreleased) HEAD!
Yeah, these facts are in tension. Then again, looking further, a lot of the recent activity has been documentation and dependency tweaks, along with some light backporting activity (since they're also continuing to support Jekyll 3). So I think the needle I'd thread here is: "the project is receiving active attention, but is sufficiently stable to not warrant regular releases."
Deviations from their previous release schedule are certainly noteworthy, but release schedules also naturally length as projects mature.
And then there's the Theseus-type questions: if Jekyll changes its name because the current maintainers have lost access to the RubyGems credentials, is it really not Jekyll anymore? It occurs to me that OSS is replete with `${project}-ng` namings, the `ng` suffix typically indicating that the project serves the same purpose as its original form but has been moved to a different namespace for whatever reason. If Jekyll's current maintainers were to publish `jekyll-ng` on RubyGems, I'd be inclined to call that a continuation of the original Jekyll for all extents and purposes.