-
Notifications
You must be signed in to change notification settings - Fork 0
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
please remember keeping versions updated #1
Comments
Thanks for pointing out. I will ensure that for future releases version number and the name are properly modified. Not sure how I missed this step. Is it appropriate to edit this information for Release v1.1 and re-upload the modified APK or should I keep this change for future releases? As far as I know, when you are editing the release, GitHub makes a new snapshot of the source code tree and attaches it as a .tar. If this is true, editing the release now will result in a confusion since I recently pushed some changes that I made long time ago along with fixing typos in README and those changes should not be included in a snapshot along with Release v1.1 What are your thoughts on this? |
That's your decision – and might depend on how you want to approach that. If your app is not yet listed on any store (which I assume, as otherwise you'd have noticed this problem earlier), there's no real problem with editing a release. You could simply replace the attached APK – but then, that would not correspond to the commit the tag/release is associated with (not a big deal in this specific case, but still might cause some confusion). Easiest would probably be to make a "maintenance release" (e.g. v1.1.1) at the proper commit, so all is "in sync".
Not if you only adjust the release comment or add/remove attachments (would make no sense, as they'd need to build the very same tarball from the very same commit they did before). But anyhow: I'd suggest making a "maintenance release" at a commit where you've fixed the versioning. That could happen in two ways:
If you go with a branch the remaining question is just if you want to retain that branch "forever" – because if you delete it, the tag would point to NIL 😉 Just let me know when a release with a properly versioned APK is up please, so I can include your app with my repo 😃 |
The new release is now ready! In addition to fixing the versioning issue I decided to also upgrade dependencies and fix some visual issues (temporarily). I am glad to be invited to your app repository! You are free to test the release if you want and tell me about any issues other than these listed under Known Issues. I also have a small question. I know that when you are publishing for F-Droid, you should add the fastlane metadata thing. Do I have to do anything like that before you will be able to publish the app in your repository? I also released this useful app somewhat recently. Maybe you will be interested in adding it to your repository as well. |
Integrating it with my repo at this very moment, thanks! Be welcome to pick a badge for integration with e.g. your Readme, to link to where it will show up with the next sync!
Set up now in my repo – so if you need it, let me know and I'll send you a PR with a "starter package" 😃
Taking a look now, thanks! |
I don't really understand what you meant to say here 🥲 However, judging from your message, you have already filled all of the data yourself. So, I will only need to update the metadata when I make a new release or something, right? Also, how are changelogs handled in such application repositories? Are they just scraped from GitHub (and other code hosting services) releases or should they be provided in the metadata? And I also have an additional question to ask, while we are at it. I know that such repositories as yours are mainly focused on providing open source apps. People in F-Droid's Matrix chat said I can not publish games made with proprietary engine, such as Unity, to F-Droid (given that the game itself is open). How is that in your repository? |
OK, phrasing it differently: your apps are both live now in my repo – and when you want to bring them to F-Droid.org and thus need Fastlane, give me a ping and I provide the necessary files via a pull request to your repo here 😉
Definitely! That's the idea. You know best when things need to be changed there 😄
Whenever you feel something needs to be changed – and yes, updates to that would be picked up along with the release then.
By your providing them with the Fastlane structures. Be welcome to my Fastlane Cheat Sheet 😃 As for games: I usually do not include games at all with my repo. But other than F-Droid, I have no means to check your build process as I only pick the APKs. So all I can check are the resulting APK files and what they contain – not how stuff got in there. |
So cool! Thank you! Anyways, as everything seems clear now, I am closing the issue. |
… and continue "over there" 🙈 |
Currently there are two releases tagged, v1.0 and v1.1. The APKs on both identify as
because versions were not updated – so they are hard to keep apart:
versionName
wasn't changed, folks cannot really see which version they have installedversionCode
was not updated, Android will not recognize v1.1 as update to an installed v1.0Can you please keep track of that with future releases? Thanks in advance!
The text was updated successfully, but these errors were encountered: