Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

packageName changed? #93

Open
IzzySoft opened this issue Nov 21, 2023 · 7 comments
Open

packageName changed? #93

IzzySoft opened this issue Nov 21, 2023 · 7 comments

Comments

@IzzySoft
Copy link

Before the current release, the package name of the arm64 build was tech.laihz.alga.arm64 – now it is tech.laihz.alga. Is that a temporary glitch – or intended to stay? My repo refused to accept it because of the different packageName (which it doesn't know):

WARNING: tech.laihz.alga.arm64_37.apk (tech.laihz.alga) has no metadata!

ReleaseNotes give no clue (or I missed it).

@laiiihz
Copy link
Owner

laiiihz commented Nov 22, 2023

dev release is not the final release. 💙

sorry for change, its not a glitch, next stable version of alga will change the package name to dev.laihz.alga. this is gonna be a breakchange for everyone.

by the way i lost my android build key & password so i think its time to change a diffent package name. 😂

@laiiihz laiiihz pinned this issue Nov 22, 2023
@IzzySoft
Copy link
Author

So from now on, regardless of the ABI, all APKs will have the same package name? That seems reasonable to me (as one can easily switch between armeabi and arm64 then, like when upgrading from some old 32bit-only device to a 64bit one or having to revert to the former in case the latter needs to be sent for repair).

OK, I'll see to make the transition then. A "cold switch" (simply renaming) is fine with you? Or should I let the "old variant" stay for a little longer, with a comment of the status to give folks a chance to notice?

by the way i lost my android build key & password

That is very bad. As you're not signing your commits, how to confirm it's really you? If I may recommend you a reading: How to keep your key safe and what measures to take for the event of loss? (no offense meant, just a "friendly hint" – it's always good to know the options one has to keep things safe). Not sure if there are any options left to "salvage" the current loss (if there are it's appreciated to take them, to "push up trust"), but cannot hurt to take some of the precautions for the future 😉 Switching to a new packageName of course "covers this up" a bit – so it's a little like "establishing a new app".

Thanks for giving some background on the change! Waiting for your reply to the second paragraph then before I take action here.

@laiiihz
Copy link
Owner

laiiihz commented Nov 22, 2023

@IzzySoft Yes, in future release, all abi will have same package name.

I am really sorry for the change, could you please keep the old variant for a litter longer, this month (or this week) i will start build with f-droid and release a new stable version of alga. when all works are done, i will put comments here #93.

  • using dev.laihz.alga package
  • build with f-droid and add metadatas
  • next stable version CHANGELOG add more infomation about changing package name

How to keep your key safe and what measures to take for the event of loss?

this is wonderful article! i realized that is a real problem about lost my build key.

and last thank for the advice and your patience comments! ❤️

@IzzySoft
Copy link
Author

in future release, all abi will have same package name.

Good!

could you please keep the old variant for a litter longer

I can simply "freeze" it and set a reminder to remove it towards the end of this year, no problem.

will start build with f-droid

You mean getting your app to F-Droid.org? So shall I just freeze the last version with the "old" packageName and wait for that (as with F-Droid, the signature might change again should you not be able establishing reproducible builds) – or do you want me to establish the "new app" with my repo right now (or after the release you just described, with the changelog and all)?

this is wonderful article!

Thanks! Glad you liked it and it helped you!

and last thank for the advice and your patience comments!

Gladly given. I'll give my best to continue that where needed 😊

@laiiihz
Copy link
Owner

laiiihz commented Nov 23, 2023

I can simply "freeze" it and set a reminder to remove it towards the end of this year, no problem.

Thanks!

You mean getting your app to F-Droid.org? So shall I just freeze the last version with the "old" packageName and wait for that (as with F-Droid, the signature might change again should you not be able establishing reproducible builds) – or do you want me to establish the "new app" with my repo right now (or after the release you just described, with the changelog and all)?

Yes, i'm working on publish to F-Droid those days(I'm new to this, need couple days), i guess establish a "new app" and freeze the old package maybe a simplist way for you and maintain your repo. And just freeze the "old" packageName. 🙏

this issue will not close until all migration works are done

@IzzySoft
Copy link
Author

Freeze established, switch initiated. *.arm64 set for removal after 2023-12-31, the new one should show up with the next sync around 5 pm UTC (i.e. in about 2 hours).

@ClockGen
Copy link

Hello @laiiihz, I can help with F-Droid packaging if you want. Packaging flutter apps is tricky, especially if you want reproducible builds enabled (https://f-droid.org/docs/Reproducible_Builds/). If that's the case, then we must use the same flutter version, have the same build environment, perform build of the app in the same directory both on f-droid and your side (assuming that you run linux or use some CI), and lots of other quirks. In return, F-Droid will be able to publish your apk with your signature, while without reproducible builds F-Droid will simply build and sign the apk with f-droid key.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants