Currently, the plugin uses names to store players information.
However, when a player changes his name, he loses all his Parkour legacy (level, parkoins, stats...), and I learned that it happens more frequently than what I had thought.
I usually just tweaked directly the configuration, but it is not a viable option, and it would be really nice to see the plugin uses UUIDs directly to avoid such problems.

I already started some preliminary work here: https://github.com/Prodrivers/Parkour/tree/dev
It is still WIP, but it lays out the main idea, which is to centralize every storage manipulation in dedicated methods, and switch most player methods to use a Player object instead of names directly. It becomes then easier to use UUIDs.

What are your thoughts on this ?

Absolutely I agree with your idea. I was talking to steve about refactoring a large part of the plugin.
I was going to release 4.2 for the ParkourKits, then use Parkour 4.3 to make any drastic changes to.
UUID's are definitely the way forward, thanks

Going to decide against doing this task now, it's too major for a minor and questionable benefit.
If required the usernames can be easily be edited in the configs and database.

The benefit is clear: players change their names constantly. UUID is the correct id method, used by hundreds of plugins. Please reconsider.

I personally will not be undertaking this task, there's way too much consider and potential problems with backwards compatibility, and as mentioned the benefit does not justify the amount of the work involved.

In terms of priority it's at the bottom of the list, considering my other plugins also require updates.
I will reopen it for the chance that another developer creates a stable implementation which I will implement into the plugin.

Thank you.

Parkour v6.0 seemed like a good time to do everything properly. All player data will be stored using their uuid as the key, ParkourSessions will be captured with their uuid as the file name, and all database entries will use the uuid as the key for looups.
Backwards compatibility will be a nightmare, but I'm hoping to write a clever upgrader that should convert from an old system to new.

Unfortunately I think it will indeed be a nightmare. When I introduced an UUID field in my database using a custom script, I had a handful of usernames that were not cached by the server anymore and I had to request Mojang APIs for that. Still, I wasn't able to automatically decide which account is the "good" one when the username was claimed by at least two different accounts without looking at the respective account's username history, and I cannot think of a good way of doing that automatically right now. I had to do it manually at that time.

Personally, it does not bother me to lose some user data in the process, as I can manually add them back if a user reports it, but obviously not everyone will agree on that.

I decline to Discord. But no worries -- I'm patient.

I'm happy the plugin is now working without any references to player name, using UUID to store times in the database, creating ParkourSession snapshots using the player's UUID as the lookup.
The upgrade process will use the Mojang's API to get the matching UUID for the existing player at that point in time, if it's wrong then it will require manual editing, but that's at a per-server discression.

Thank you. When might we expect Parkour 6.0 ?

Hoping within a month, most of the new features have been added and now it's a matter of tidying up the code, documentation and testing.
If you wish to join the Discord you can keep track of progress and download development snapshots.