Update on the state of this library

[cogsandsquigs]

While I love using this library, part of me is worried due to the fact that there are many new issues open as of late, yet the last commit was in late 2022. Part of me is worried that this means that the library is becoming less and less maintained. Therefore, I have two questions:

1. Is this library still actively maintained? If so, why has there been no recent activity? If not, why is that the case?

2. Will this library every reach a v1.0.0 semver? i.e., will this library ever reach a stable state if still maintained? If this library is considered stable, why is it not at a version 1? If this library is not stable, is there anything that can be done to get this library in a stable state/version 1 semver?

I would really like to see this library still be maintained and actively contributed to (especially because I use it and like it). Hopefully it can start to either implement new features and updates, or work towards a stable version 1 release. Either way, any comment, suggestion, or insight into this library is appreciated.

[shepmaster]

Yes, it's maintained.

there are many new issues open as of late

I count 7, including this one, opened this year. 2 are questions about using the library and have answers, 2 are feature requests that no one has submitted PRs for, one is an issue with a deliberately unstable feature, one is an issue with interaction of uncommonly used features, and one was opened two days ago and has had discussion on it. Exactly what do you think is missing?

Will this library every reach a v1.0.0 semver?

That's a good question! Over time, I've had various goalposts in mind for what the big shiny 1.0 should be. Those goalposts have themselves been moved over time as well. For example, some that I recall:

• when the standard library gets stable backtraces
• when the error trait moves to libcore
• when the provider API is stabilized

Right now, I don't actually know what I'd want to see for a 1.0 release. Part of that reason is that 0.5 / 0.6 / 0.7 are basically the same as 1.0 to me (and this is how Cargo encourages and interprets version numbers) — I have a reasonable test suite attempting to ensure functionality and compatibility.

Hopefully it can start to either implement new features

Is there a specific feature that it lacks that you are waiting for?

---

As a mental exercise, say I took the current release and re-published it as 1.0 with zero functional changes. What would that mean for you that's any different from today?

[8573]

There is #132 for tracking to a 1.0 release, although it's not tracking much at the moment.

Number of open bug reports

Looking over the open issue tickets, I see only four, over all years, that either are tagged as "bug" or are not tagged and look like they might be bugs: #341, which looks like a simple documentation oversight; #370, which has a clear fix but entails a breaking change (especially without anyone's saying they need that fix, I think it seems sensible to batch it up with other, future breaking charges); #373, which concerns an experimental feature of nightly Rust and seems like mostly a support ticket; and #376, about using futures with no_std. ...I guess this doesn't really answer you if you're wanting 'new features'.

[cogsandsquigs]

@shepmaster Generally, I’d be pretty fine if this latest release was packaged as a 1.0 — I haven’t encountered anything that I’d really want to change. I was just worried about the lapse of updates/commits given standing issues, but your response is reassuring. I didn’t really mean to ask for new features (I don’t really want any as of right now), but was just wondering if there would be any as time goes on in response to the issues opened. As long as this library is maintained well, I’m happy — I just wanted to make sure that was the case.