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

Release v5.0.0 #5528

Closed
6 tasks done
sivaraam opened this issue Feb 9, 2024 · 15 comments
Closed
6 tasks done

Release v5.0.0 #5528

sivaraam opened this issue Feb 9, 2024 · 15 comments
Assignees

Comments

@sivaraam
Copy link
Member

sivaraam commented Feb 9, 2024

We're due the release of v4.3.0 v5.0.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

Post release

@sivaraam sivaraam self-assigned this Feb 9, 2024
@sivaraam sivaraam pinned this issue Feb 9, 2024
@sivaraam
Copy link
Member Author

sivaraam commented Feb 9, 2024

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
Copy link
Contributor

kanahia1 commented Feb 9, 2024

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

@nicolas-raoul
Copy link
Member

@sivaraam Created #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
Copy link
Member Author

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
Copy link
Member

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

@sivaraam
Copy link
Member Author

sivaraam commented Apr 9, 2024

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
Copy link
Member Author

@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
Copy link
Member

@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
Copy link
Contributor

mnalis commented Apr 17, 2024

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 😢

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
Copy link
Member Author

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 sivaraam changed the title Release v4.3.0 Release ~v4.3.0~ v5.0.0 Apr 28, 2024
@sivaraam sivaraam changed the title Release ~v4.3.0~ v5.0.0 Release ~~v4.3.0~~ v5.0.0 Apr 28, 2024
@sivaraam sivaraam changed the title Release ~~v4.3.0~~ v5.0.0 Release v5.0.0 Apr 28, 2024
@sivaraam
Copy link
Member Author

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
Copy link
Member Author

@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
Copy link

linsui commented Apr 28, 2024

Done. :)

@sivaraam
Copy link
Member Author

Thank you @linsui ! 🙂

@sivaraam
Copy link
Member Author

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 🙂

@sivaraam sivaraam unpinned this issue Jun 8, 2024
@sivaraam sivaraam mentioned this issue Jul 6, 2024
8 tasks
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

6 participants
@nicolas-raoul @mnalis @sivaraam @linsui @kanahia1 and others