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

please remember keeping versions updated #1

Closed
IzzySoft opened this issue Apr 13, 2023 · 8 comments
Closed

please remember keeping versions updated #1

IzzySoft opened this issue Apr 13, 2023 · 8 comments

Comments

@IzzySoft
Copy link
Contributor

Currently there are two releases tagged, v1.0 and v1.1. The APKs on both identify as

package: name='com.smoothie.monetcolors' versionCode='1' versionName='1.0'

because versions were not updated – so they are hard to keep apart:

  • because versionName wasn't changed, folks cannot really see which version they have installed
  • because versionCode was not updated, Android will not recognize v1.1 as update to an installed v1.0

Can you please keep track of that with future releases? Thanks in advance!

@Smooth-E
Copy link
Owner

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?

@IzzySoft
Copy link
Contributor Author

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?

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".

As far as I know, when you are editing the release, GitHub makes a new snapshot of the source code tree and attaches it

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 feel the current HEAD fine for that: increase VC to e.g. 3, set VN to e.g. 1.1.1, commit, tag, release.
  • if you feel it in a state not fit for release: create a new branch off the last commit you feel fit, adjust VC/VN there, commit and create a tag/release on the commit in that branch. Then either merge that branch back to main, or simply repeat the versioning adjustments on main at its HEAD.

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 😃

@Smooth-E
Copy link
Owner

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.

@IzzySoft
Copy link
Contributor Author

The new release is now ready!

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!

I know that when you are publishing for F-Droid, you should add the fastlane metadata thing.

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" 😃

Maybe you will be interested in adding it to your repository as well.

Taking a look now, thanks!

@Smooth-E
Copy link
Owner

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"

I don't really understand what you meant to say here 🥲
Yeah, sure, make that pull request. I guess, filling out the metadata myself will give me more control on how the app looks in the store.

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?

@IzzySoft
Copy link
Contributor Author

I don't really understand what you meant to say here

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 😉

Yeah, sure, make that pull request. I guess, filling out the metadata myself will give me more control on how the app looks in the store.

Definitely! That's the idea. You know best when things need to be changed there 😄

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?

Whenever you feel something needs to be changed – and yes, updates to that would be picked up along with the release then.

Also, how are changelogs handled in such application repositories?

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.

@Smooth-E
Copy link
Owner

So cool! Thank you! Anyways, as everything seems clear now, I am closing the issue.

@IzzySoft
Copy link
Contributor Author

… and continue "over there" 🙈

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

2 participants