Say why bundles are still unlocked, which is not the reason written down - #116
Merged
Conversation
Both places claimed nothing can open a locked bundle. The app on main can - zip4j is in app/build.gradle.kts and AppleZipImporterUtil uses it - so the comment reads as a stale note about a missing feature, and the obvious next step is to turn locking on. That would be wrong, and the real constraint is release ordering. The newest Android release is 1.0.5, from before that work, and versionName has not moved past it: no *installed* app can open a locked bundle. Locking now produces files nobody can import, and it lands hardest on recipients, who did not choose the exporter's version and cannot fix it from their side. So the comment now names the condition that unblocks it - an Android release containing zip4j - rather than a capability that already exists. docs/android-import-handover.md §3 is already marked done and needs nothing.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two comments claimed nothing can open a locked bundle. That is no longer true, and the way it is false matters — because the obvious next step from the old wording is to switch locking on, which would break things for users.
What is actually true
mainapp/build.gradle.ktsandAppleZipImporterUtiluses itversionNameonmain1.0.5— the import support is unreleased and has no version numberSo the constraint is release ordering, not a missing feature. Locking bundles now would produce files that no installed app can open, and it lands hardest on recipients — who did not choose the exporter's version and cannot fix it from their side.
What changed
Only comments and one
--helpstring. No behaviour.Both now name the condition that unblocks this — an Android release containing zip4j — rather than describing a capability that already exists. Once one ships, this becomes a decision about how long to support the versions before it, which is a real decision rather than a TODO.
Checked and left alone
--no-passwordrow already says "Required for any released version of the app", which is exactly right.docs/android-import-handover.md§3 is already marked done and documents the zip4j work.PR description summarised by Claude Code.