ETA for next release

[o2sh]

Hi @XAMPPRocky,

Do you have an idea when the next release will be?

Since v12.1.2 was released in January 2021, there have been a couple of useful updates that onefetch is waiting for. Specifically #840 and #880 (not yet merged)

Cheers.

And thanks for the amazing work that you've done here 👍

[XAMPPRocky]

Thank you for your issue! There is currently no release date planned for the next release. I'm currently focused on other projects that have paid work attached to them. That's not to say there won't be a new release, I just have a few things I want to implement before releasing the next version. Right now it could be within the next three months, by the end of the year, or next year depending on when and how much time I get to work on tokei.

(P.S. If you'd like to see a release happen sooner, sponsorship support directly affects how much time I can spend on projects like tokei https://github.com/sponsors/XAMPPRocky)

[CosmicHorrorDev]

I should have some spare time coming up, so if you are kind enough to throw together a roadmap linking to issues you would like to be worked on then I should be able to pick up some work :D

[XAMPPRocky]

@LovecraftianHorror Thank you for the kind offer, however as you can probably tell, I don't have much time to respond to issues, so I wouldn't even have the time to create a whole plan and all the subsequent sub-issues, and while there are some features I want to add, not all of them are straightforward additions, some are infrastructure problems that require my credentials, some are much more bespoke problems that require a lot of design work that I need to work on to see if it's even possible, so I wouldn't want to create a plan saying "there will be a feature that does X, Y, Z" when I don't know if I can cleanly fit it into the current project or if it's really a good idea at all.

That being said of course, PRs for issues marked with help wanted are always welcome, and if there's something where I know what would need to be required, I'll try to make issues in case I don't have the time to immediately implement it.

[ErikSchierboom]

@XAMPPRocky I was wondering if you perhaps have an idea when the next release would be? #920 was merged relatively soon, and we'd like to use it in our systems.

[XAMPPRocky]

@ErikSchierboom No, the above message hasn’t changed. If you’d like to use latest you can always install from main with cargo.

cargo install --git https://github.com/XAMPPRocky/tokei.git

[ErikSchierboom]

@XAMPPRocky Okay, thanks for the quick reply!

[kornelski]

@XAMPPRocky Could you reconsider your plans? Outdated dependencies are a pressing problem. Bigger improvements can wait, but it'd be great to just have tiny maintenance release that fixes the deps.

[XAMPPRocky]

@kornelski I can't reconsider what I do not have the bandwidth to do. There are already breaking changes in main and I do not have the bandwidth to backport all the fixes. If they are so pressing then where is the money to fund this urgency? Currently GitHub sponsorships don't even cover a tenth of my rent, so please understand that your urgency to get timely fixes is trumped by my urgency to keep the lights on.

[spenserblack]

Would you be open to contributors backporting the fixes? If you make a branch like v12 from the latest release tag, I'm sure some users that are looking forward to a new release would be happy to backport those fixes (and non-breaking features) via PRs targeting that branch for you.

[XAMPPRocky]

@spenserblack If I don't have time to do it myself, I certainly don't have to review other people's work. I appreciate that people want to help, but just throwing more labour at the problem requires more time and work on my part to manage it all which is the exact thing I can't do right now. This a problem that's only solved by enabling me to spend more time on tokei, and until that's possible, people can expect to wait.

[kornelski]

@XAMPPRocky It doesn't seem like you will find time to work on this project anytime soon. Could you pass it on to someone else? I'm volunteering.

[XAMPPRocky]

@kornelski You're more than free to fork the project if you so choose. With respect I wouldn't add a maintainer who wasn't already a regular contributor who I felt understood the goals and intentions of the project.

Counting code is an inherently opinionated feature, so I wouldn't want to handover the project to anyone. I think it's more productive to produce a different tool like loc or scc maintainers did.

---

There will be a release soon, along with a regular schedule of releases. I'm still merging PRs, so clearly I'm still interested in maintaining the project, the release management has just gotten to be too much to handle, which is why it will soon be automated out of my hands.

[spenserblack]

I wouldn't add a maintainer who wasn't already a regular contributor who I felt understood the goals and intentions of the project.

Just curious, do you currently feel like you need (or at least strongly want) additional maintainers, or are you happy being the sole maintainer for now? It's perfectly fine if you want to be the sole maintainer, it's your project after all!

However, if you are looking for teammates to help maintain this project, could I suggest adding a "looking for maintainers/collaborators" issue and pinning it? It would at least be a good place to document the criteria to be a maintainer, which I assume would at least include these:

• Must prove you have the knowledge and interest to maintain by being a frequent contributor
• Must understand and agree with the goals of this project

At the very least, if you get asked about adding maintainers again, you can just point to that issue 🙂

[XAMPPRocky]

Just curious, do you currently feel like you need (or at least strongly want) additional maintainers, or are you happy being the sole maintainer for now?

Well I think this is slightly the wrong question to ask, as while additional maintainers are helpful and can make more work possible, that's not what the original issue is about. It's about "when is the next version of tokei?", and more broadly "what is the release process/schedule/cadence tokei going to be?", and the best answers to those questions for users would not be sustainably solved by adding more people. Which is why I've said the working solution is to automate the process. I'm working towards it on other smaller crates than tokei first.

[XAMPPRocky]

Also to alleviate some of the issue and help test the current codebase before moving to a regular release version and cadence, tokei 13.0.0-alpha.0 is now available on crates.io for people try out.

[spenserblack]

the best answers to those questions for users would not be sustainably solved by adding more people.

To be fair, when the main delay to a release is a lack of availability, having a trusted maintainer with authority to merge PRs and create new releases can be helpful. Even if the release process becomes easier and faster with automation, as long as some human action is required (like pushing a tag), there can be circumstance where it becomes impossible for the sole maintainer to keep up timely releases. So, yes, adding maintainers might not directly address "when is the next release?", but I'd argue that it does address a question that it raises: "can we rely on continued future releases?"

As an extreme example, there was quite a bit of concern when it was believed that the only person with publish permissions for core-js would be unavailable for an extended time.

P.S.: Thanks for you hard work maintaining this repo, though!

[XAMPPRocky]

So, yes, adding maintainers might not directly address "when is the next release?", but I'd argue that it does address a question that it raises: "can we rely on continued future releases?"

You see I'm not sure I'd agree, it would definitely solve it in the short term and get the current code out the door, but in my experience maintaining repositories, people who have time today, will eventually be busy tomorrow, since this isn't a commercial project, there's very little extrinsic motivation for a maintainer on tokei. So while I think that bringing on someone would help release this version of tokei, I also think we'd eventually hit a point where that person is just as time-constrained and can't do release management anymore.

[ErikSchierboom]

Which is why I've said the working solution is to automate the process. I'm working towards it on other smaller crates than tokei first.

Lovely!