Release v4.3.0

[sivaraam]

We're due the release of v4.3.0 soon. Thanks to our volunteer community, we have significant things such as the migration from Mapbox to OSM droid, other enhancements, removal of the data-client module and various bug fixes. 🙂

It would be ideal if we iron out few things before the release, though. For instance, we could look into converging the following MR that fixes some issues in Nearby: #5494

Feel free to chime in if there other such things which we should certainly handle before release.

Checklist

• [ ] Converge the following MRs
  • [ ] #5494
  • [ ] #5525
• [ ] If possible, a fix for #5218

Post release

• [ ] Tweak data safety form to clarify we don't gather telemetry

[sivaraam]

There's this one thing about the switch to Mapbox that bugs me a bit. The speed at which tiles are loaded has drastically reduced after the switch IIt takes several seconds for the tiles to load.

Is this just me or does this also happen to others too? If yes, we should likely open a separate issue about this amd discuss there.

[kanahia1]

@sivaraam This also happens to me, osmdroid takes time to load tiles for first time.

[nicolas-raoul]

@sivaraam Created https://github.com/commons-app/apps-android-commons/issues/5529 about slow maps, I don't think that should delay release though, as it may take time to solve and is still quite usable.

[sivaraam]

There's a user report now about the app not showing user statistics. We should plan on releasing v4.3.0 soon.

Commons talk link: https://commons.wikimedia.org/wiki/Commons_talk:Mobile_app#c-Alex_Blokha-20240321230800-App_shows_error,_when_dispalying_stats

[nicolas-raoul]

I don't really think we need to wait for 5494 and 5218. Any other blocker?

[sivaraam]

The only reason, I kept #5494 as a blocker is because it fixes many broken flows in nearby / explore map screens. It's already in a decently ready state. So, we shouldn't have trouble merging it down for this release.

The only other blocker is getting the release notes for this release. There have been a huge amount of changes. I hope the MR title and descriptions are clear enough to easily draft release notes from them. 🙂

[sivaraam]

@nicolas-raoul This issue seems like a regression when compared to v4.2.1. It seems like it might be bad UX in locations where multiple pins could be present. So, should we fix that before releasing v4.3.0?

[nicolas-raoul]

@sivaraam It is a regression indeed, but not an important one because:

• It is rare that there are so many pins close to each other.
• Any user would typically zoom in before choosing a pin.
• The place name is also visible at the bottom. So it should not delay release. :-)

[mnalis]

I'm a big fan of "release early, release often". It reduces anxiety, gives better feedback to users, and smaller changes means easier triage of new bugs (e.g. if regression was introduced in just the last release which changed just a little code, it is much easier to find why/where than if there is a ton of new code to wade through).

It's already been half a year since the last release. I'd love to see new one. There've been few issuees I wanted to test if there were fixed, but by now I've even forgotten what they even were :cry:

Then, when that #5692 (and perhaps a few others) are fixed, 4.3.1 can easily be released in a month or two, no problems.

[sivaraam]

Makes sense, @mnalis 🙂

I'll look into releasing v4.3.0 soon-ish. We could do iterative smaller releases soon as you suggest. Let's see if we could change the release cycle to make it a montly release at the least 👍🏼 Don't hesitate to nudge us if we don't do so 😉

[sivaraam]

Rolled out v5.0.1 for testing just now. Yeah, I thought it made total sense to bump the major version considering the quantum of changes that has gone [ref] 🚀

Thank you very much to the contributors for all your invaluable contributions! It is great to see so many contributors willing to improve the app and thus contributing to the Wikimedia Commons community in some way. ❤️

---

The released version is v5.0.1 and not v5.0.0 as we hit the ProGuard trimming issue in v5.0.0. That went unnoticed and the release variants were literally broken. So, I tweaked the rules in this commit and bumped the version to v5.0.1 to avoid removing the existing tag.

I did release the v5.0.1 after testing all the major flows work fine. Regardless, @psh could you kindly take a look at this commit and ensure that I've not accidentally excluded any package that should be excluded from R8 trimming?

On a side note, I also created a release for v4.3.0 as I realized that it is ideal to bump the major version after pushing our the v4.3.0 tag. It's just there for reference purposes.

---

On another side note, GitHub has the great release notes generation ability which works after the tag is published. If anyone is aware of how to use the same without pushing the tag, kindly let me know. It would be helpful for adding the entries in CHANGELOG file 🙂

[sivaraam]

@linsui There are two tags v4.3.0 and v5.0.0 which contain non-working code (unfortunately). Could you help us with disabling both of those from being published in F-droid?

Only the v5.0.1 one has working code.

I hope this time it should be easy as all versions have different version name and version codes 🙂

Will try to avoid this issue in future 👍🏼

[linsui]

Done. :)

[sivaraam]

Thank you @linsui ! 🙂

[sivaraam]

I've initiated a staged rollout of the app to Production on Google Play. So, it should be available to users in a few days 🙂