About the update window

[HGBits]

I wanted to talk about the updates that implemented issues #152 and #145, new functions should not be implemented in this way directly into production. there are some bugs that I'm tracking now, anyway there's nothing that can be done is to fix and ensure that future updates that implement new functions are released in Beta initially with the proper tests to ensure compliance.

In addition to bug #184 already reported, there are also problems related to the support of external keys, but one thing at a time. After the critical issue that immediately affects is solved, then I can report this other one in more detail.

[pando85]

Thanks for raising this. I agree with part of the concern, especially that when bugs are found around new functionality we should improve the tests so the same class of problem cannot easily come back.

That said, I don't think I want to move the project towards long-lived beta/stable branches or freeze "main" while new functionality spends a long time in a separate branch.

The approach I've been trying to follow with this fork is intentionally fairly aggressive: implement useful functionality, test it as much as reasonably possible before merging, release it, get real-world feedback and fix regressions quickly. For a relatively small project I think this gives us a much shorter feedback loop than maintaining several versions of the application in parallel.

That doesn't mean that releasing bugs is acceptable, of course. In particular, this is a password manager, so issues involving encryption, key resolution or modification of the password store need to be treated carefully. When we find bugs in those areas, I think the right response is both to fix them quickly and, whenever possible, add regression tests for the invariant that was broken.

I also think there is a useful distinction between experimental features and experimental branches. For new functionality that is inherently experimental, I would rather make it clearly opt-in/isolated and allow interested users to exercise it in normal releases than keep a separate development branch alive for a long time. If a feature turns out to be fundamentally unsafe or too unstable, reverting it is also an option.

I'm not against prerelease/Beta builds when there is a concrete reason for them, particularly for a particularly invasive change. But I wouldn't like Beta to become a mandatory stage that requires us to maintain separate release branches and backport fixes between them. Ideally "main" remains releasable and we keep a single line of development.

Regarding the bugs you're finding: please keep reporting them. The feedback is genuinely useful, especially when you can provide the kind of detailed reproduction you provided in #184. I'd much rather iterate quickly on those problems and improve the tests around them than slow development down by default.

So I think we probably agree on the goal — avoiding regressions and protecting existing functionality — but perhaps differ a little on the release strategy used to get there.

[HGBits]

I'm going to spend a few days out of the repository, I'm burning my AI tokens in a complex alternative project.

Just communicating the situation, because of this I will not be able to map the bugs to provide the reports, but there are two distinct problems still pending that are critical. the first one is that version 1.25 did not solve the problem of "Missing.gpg-id file", selecting a key as requested closes the application. which raises a question what format for the.gpg-id is accepted? I'm using email. maybe that's the problem? it's worth testing later, another time I'll check this. The second problem is that using a keyring of keys is useless for two aspects: 1- in the process of generating the pass, it requires inserting keys manually, there is no flow to pull the keyring 2- even if you connect the keyring, there is still the key in place, which nullifies the keyring's usefulness.

[HGBits]

[HGBits]

Without doing a deep debugging I won't be able to pinpoint the problem, but something in the normal environment breaks. I'm using Android 12, I haven't tested exporting the keys and testing in this same condition outside of Shelter.

[HGBits]

ok, I just did the same test exported the keys and using it directly in the normal environment without the shellter and the "missing gpg" warning appeared this time, so we can rule out the link with the cloning process of the remote.

[HGBits]

Apparently the only chance I have left is that obviously using the Shelter solves some problem in my environment with the Pass. Are there any specific Android 12 bugs that you are aware of? I'm out of options.

[HGBits]

I identified the problem, debugged it manually via adb and found the problem, I passed the issue to the AI to write the detailed issue.
#189

hellish debug section. haha. I'm going to take a break and go back to my other project.