ETA on next release please

[garthsch]

Several issues and PRs have been closed recently, but without updates on the main branch or next release, it's hard to tell what state the project is in. This is causing duplicate issues to be filed. Could we get a quick status update or ETA on the next release?

[bak3r]

Does anyone who has member access (https://newsletter.danielmiessler.com/upgrade) know if enrolling in it gets you access to more frequent updates for this project?

[garthsch]

There's no special member section or faster updates for subs.

Though it's not a bad idea, given how much Daniel is spending on time and tokens for this project.

[garthsch]

Following up on my own question with more detail, because I don't think "release more often" is quite the right ask.

The work does land, in Issues and PRs. What nobody can tell is whether it's wasted. You can't know whether a fix has already been made privately, whether the direction is one you'd want, or whether an integration actually solves the problem the original poster had. Duplicate issues get filed for the same reason. Experienced people are spending real time and their own tokens contributing blind, and that's harder to sustain than a slow release ever would be.

A status note would help with that, but it isn't the whole of it, because the thing people want isn't only information. There's a lot of contributor capability in this project with nowhere confident to point to.

Which leads to the part I'd genuinely like your read on. If what's eating the time is separating your own content from the public tree and then checking it by hand, that's worth treating as a design problem rather than a chore, because it's the one item on the critical path that needs none of your private data. My instinct is that a scan asking "does this file contain something personal" can never fully close, since it's a judgement call, whereas a check asking "is this path on the list of things that ship" is decidable and can fail closed on anything unclassified. Whether that's the right shape here I honestly don't know. It would need someone who does this professionally, with real experience of sensitive-data handling in build pipelines, to say what it misses.

So rather than proposing an implementation: is that a direction you'd want help exploring, and would you say what "clean enough to ship" has to mean for you? If the answer is yes, several of us could work it through properly against invented test data, with nothing of yours involved, and bring you something to react to instead of another PR you have to assess cold.

[Drizzt321]

Hm, last I recall, Daniel was still in the process of moving towards a more public working main/dev sort of thing, rather than merging fully privately. Not sure what the state of that, but I recall it was mentioned previously that that was his intention.

[danielmiessler]

Thanks @garthsch, and you're right that the lag makes it hard to tell what's already handled. The next release is being prepared now and carries the fixes reported since v7.40.4. Each of those issues and PRs gets a reply naming where its fix landed, so you can see which reports were picked up.

[danielmiessler]

@garthsch, on the question in your second comment: the shape you describe is the one we moved to. The release build now copies only paths on an explicit list of what ships and fails on anything unclassified at the top level, with the content scans running as a second layer behind that. The release pipeline itself stays private, so it isn't something outside contributors can work on. Where help lands best is what this thread has already been doing: clean-tree reports with a repro, sent through the report workflow in the LifeOS skill so they arrive in one shape.